Postgres Performance Date Index

• Thread Index

• Re: Context switch storm
  • From: Cosimo Streppone
• Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]
  • From: Guy Thornley
• Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works
  • From: Simon Riggs
• Re: [BUGS] BUG #2737: hash indexing large table fails, while btree of same index works
  • From: Tom Lane
• Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]
  • From: Ron Mayer
• Re: 10x rowcount mis-estimation favouring merge over nestloop
  • From: Abhijit Menon-Sen
• Re: 10x rowcount mis-estimation favouring merge over nestloop
  • From: Tom Lane
• 10x rowcount mis-estimation favouring merge over nestloop
  • From: Abhijit Menon-Sen
• Re: Keeping processes open for re-use
  • From: Joshua D. Drake
• Re: Keeping processes open for re-use
  • From: Shane Ambler
• Re: Keeping processes open for re-use
  • From: imad
• Re: Easy read-heavy benchmark kicking around?
  • From: Merlin Moncure
• Re: Keeping processes open for re-use
  • From: Csaba Nagy
• Keeping processes open for re-use
  • From: Hilary Forbes
• Re: Easy read-heavy benchmark kicking around?
  • From: Luke Lonergan
• Re: Which OS provides the _fastest_ PostgreSQL performance?
  • From: Ron Mayer
• Re: Easy read-heavy benchmark kicking around?
  • From: Cosimo Streppone
• Re: Easy read-heavy benchmark kicking around?
  • From: Merlin Moncure
• Re: Easy read-heavy benchmark kicking around?
  • From: Markus Schaber
• Re: Context switching
  • From: Josh Berkus
• Re: Easy read-heavy benchmark kicking around?
  • From: Dimitri Fontaine
• Re: Easy read-heavy benchmark kicking around?
  • From: Mark Kirkwood
• Re: Help w/speeding up range queries?
  • From: Jim Nasby
• Re: Context switch storm
  • From: Cosimo Streppone
• Re: Easy read-heavy benchmark kicking around?
  • From: Scott Marlowe
• Re: Easy read-heavy benchmark kicking around?
  • From: Merlin Moncure
• Re: Easy read-heavy benchmark kicking around?
  • From: Luke Lonergan
• Easy read-heavy benchmark kicking around?
  • From: Brian Hurt
• RES: Context switching
  • From: Carlos H. Reimer
• Re: Yet another question on LIMIT performance :/
  • From: Tom Lane
• Re: Setting "nice" values
  • From: Madison Kelly
• Re: Yet another question on LIMIT performance :/
  • From: Hannes Dorbath
• Re: Yet another question on LIMIT performance :/
  • From: Heikki Linnakangas
• Re: Setting "nice" values
  • From: Tobias Brox
• Yet another question on LIMIT performance :/
  • From: Hannes Dorbath
• Re: Setting "nice" values
  • From: Madison Kelly
• Re: Setting "nice" values
  • From: Tobias Brox
• Re: Setting "nice" values
  • From: Madison Kelly
• Re: Setting "nice" values
  • From: Madison Kelly
• Re: Setting "nice" values
  • From: Madison Kelly
• [no subject]
  • From: Unknown
• [no subject]
  • From: Unknown
• [no subject]
  • From: Unknown
• Re: Setting "nice" values
  • From: Jim Nasby
• Re: Slow functional indexes?
  • From: Gene
• Re: Slow functional indexes?
  • From: Tom Lane
• Re: Slow functional indexes?
  • From: Stuart Bishop
• Re: profiling PL/pgSQL?
  • From: korryd
• EXISTS optimization
  • From: Kevin Grittner
• Re: Context switch storm
  • From: Andreas Kostyrka
• Re: Context switch storm
  • From: Tom Lane
• Re: profiling PL/pgSQL?
  • From: Jonah H. Harris
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Tom Lane
• Re: Context switch storm
  • From: Richard Huxton
• Re: Context switch storm
  • From: creimer
• Re: Context switch storm
  • From: Cosimo Streppone
• Re: Context switch storm
  • From: Richard Huxton
• Re: Context switch storm
  • From: Richard Troy
• Re: Context switch storm
  • From: Andreas Kostyrka
• Re: Setting "nice" values
  • From: Andreas Kostyrka
• Re: Context switch storm
  • From: Richard Huxton
• Re: Context switch storm
  • From: Richard Huxton
• Re: Context switch storm
  • From: Gregory S. Williamson
• Context switch storm
  • From: creimer
• Re: profiling PL/pgSQL?
  • From: Richard Huxton
• Re: profiling PL/pgSQL?
  • From: A. Kretschmer
• profiling PL/pgSQL?
  • From: Drew Wilson
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Arjen van der Meijden
• Re: Locking vs. Exceptions
  • From: Benjamin Minshall
• Re: VACUUMs take twice as long across all nodes
  • From: Vivek Khera
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Alvaro Herrera
• Re: Setting "nice" values
  • From: Tobias Brox
• Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed
  • From: Alvaro Herrera
• Re: Setting "nice" values
  • From: Scott Marlowe
• Re: Setting "nice" values
  • From: Madison Kelly
• Re: Setting "nice" values
  • From: Scott Marlowe
• Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed
  • From: Steven Flatt
• Setting "nice" values
  • From: Madison Kelly
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Dave Dutcher
• Locking vs. Exceptions
  • From: Robins
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Richard Huxton
• Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Nikolay Samokhvalov
• Re: Help w/speeding up range queries?
  • From: Simon Riggs
• Re: Help w/speeding up range queries?
  • From: Marcin Mank
• Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed
  • From: Simon Riggs
• Re: Database-wide vacuum can take a long time, during which
  • From: Matthew O'Connor
• Database-wide vacuum can take a long time, during which tables are not being analyzed
  • From: Steven Flatt
• Re: big transaction slows down over time - but disk seems
  • From: Richard Huxton
• Re: big transaction slows down over time - but disk seems
  • From: Ben
• Re: big transaction slows down over time - but disk seems almost unused
  • From: Ben
• Re: big transaction slows down over time - but disk seems
  • From: Richard Huxton
• Re: MVCC & indexes?
  • From: Ivan Voras
• Re: big transaction slows down over time - but disk
  • From: Andreas Kostyrka
• Re: big transaction slows down over time - but disk seems almost unused
  • From: Ben
• Re: big transaction slows down over time - but disk seems
  • From: Heikki Linnakangas
• big transaction slows down over time - but disk seems almost unused
  • From: Ben
• Re: pg_trgm indexes giving bad estimations?
  • From: Tom Lane
• Re: Help w/speeding up range queries?
  • From: Tom Lane
• Re: pg_trgm indexes giving bad estimations?
  • From: Ben
• Re: Help w/speeding up range queries?
  • From: Luke Lonergan
• Context switching
  • From: Carlos H. Reimer
• Re: Help w/speeding up range queries?
  • From: Tom Lane
• Re: MVCC & indexes?
  • From: mark
• Re: Help w/speeding up range queries?
  • From: Luke Lonergan
• Re: Help w/speeding up range queries?
  • From: Weslee Bilodeau
• Re: Help w/speeding up range queries?
  • From: Luke Lonergan
• Help w/speeding up range queries?
  • From: John Major
• Re: MVCC & indexes?
  • From: Alvaro Herrera
• MVCC & indexes?
  • From: Ivan Voras
• Re: Best COPY Performance
  • From: Teemu Torma
• Re: commit so slow program looks frozen
  • From: Rob Lemley
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Index ignored on column containing mostly 0 values
  • From: Andreas Kostyrka
• Re: client crashes in PQfinish
  • From: Richard Huxton
• Re: client crashes in PQfinish
  • From: soni de
• Re: Index ignored on column containing mostly 0 values
  • From: Tom Lane
• Re: Index ignored on column containing mostly 0 values
  • From: Michael Glaesemann
• Index ignored on column containing mostly 0 values
  • From: Leif Mortenson
• Re: partitioned table performance
  • From: Simon Riggs
• Re: partitioned table performance
  • From: Andreas Kostyrka
• Re: commit so slow program looks frozen
  • From: Bucky Jordan
• Re: Best COPY Performance
  • From: Stefan Kaltenbrunner
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Stefan Kaltenbrunner
• Re: Strange plan in pg 8.1.0
  • From: Steinar H. Gunderson
• Re: Strange plan in pg 8.1.0
  • From: Mattias Kregert
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Strange plan in pg 8.1.0
  • From: Tom Lane
• Re: Strange plan in pg 8.1.0
  • From: Mattias Kregert
• Re: Best COPY Performance
  • From: Spiegelberg, Greg
• Re: Strange plan in pg 8.1.0
  • From: Steinar H. Gunderson
• Strange plan in pg 8.1.0
  • From: Mattias Kregert
• Re: partitioned table performance
  • From: Simon Riggs
• Re: VACUUMs take twice as long across all nodes
  • From: Andreas Kostyrka
• Re: VACUUMs take twice as long across all nodes
  • From: Andrew Sullivan
• Re: VACUUMs take twice as long across all nodes
  • From: Andreas Kostyrka
• Re: VACUUMs take twice as long across all nodes
  • From: Andrew Sullivan
• Re: VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Re: VACUUMs take twice as long across all nodes
  • From: Andrew Sullivan
• partitioned table performance
  • From: Andreas Kostyrka
• Re: commit so slow program looks frozen
  • From: Merlin Moncure
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Michael Artz
• Re: commit so slow program looks frozen
  • From: Simon Riggs
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Merlin Moncure
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Merlin Moncure
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: VACUUMs take twice as long across all nodes
  • From: Tom Lane
• Re: query produces 1 GB temp file
  • From: Scott Marlowe
• Re: query produces 1 GB temp file
  • From: Thomas Burdairon
• Re: query produces 1 GB temp file
  • From: Dirk Lutzebäck
• Re: query produces 1 GB temp file
  • From: Alexander Staubo
• Re: query produces 1 GB temp file
  • From: Bricklen Anderson
• Re: query produces 1 GB temp file
  • From: Merlin Moncure
• Re: Regarding Bitmap Scan
  • From: soni de
• client crashes in PQfinish
  • From: soni de
• query produces 1 GB temp file
  • From: Dirk Lutzebaeck
• Re: VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Index ignored with "is not distinct from", 8.2 beta2
  • From: JEAN-PIERRE PELLETIER
• Re: query slows down drastically with increased number of
  • From: Tom Darci
• Re: query slows down drastically with increased number of fields
  • From: Tom Lane
• Re: query slows down drastically with increased number of fields
  • From: Jim C. Nasby
• Re: VACUUMs take twice as long across all nodes
  • From: Andrew Sullivan
• Re: query slows down drastically with increased number of fields
  • From: George Pavlov
• Re: VACUUMs take twice as long across all nodes
  • From: Jim C. Nasby
• Re: query slows down drastically with increased number of fields
  • From: Tom Lane
• Re: VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Re: Stored procedure slower than sql?
  • From: Jim C. Nasby
• Re: VACUUMs take twice as long across all nodes
  • From: Jim C. Nasby
• Re: Configuration Issue ?
  • From: Jim C. Nasby
• Re: OT: TCL vs Perl Re: commit so slow program looks frozen
  • From: Joshua D. Drake
• OT: TCL vs Perl Re: commit so slow program looks frozen
  • From: mark
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: commit so slow program looks frozen
  • From: Richard Troy
• Re: commit so slow program looks frozen
  • From: Richard Troy
• Re: Stored procedure slower than sql?
  • From: Matthew Peters
• Re: Stored procedure slower than sql?
  • From: Tom Lane
• Stored procedure slower than sql?
  • From: Matthew Peters
• Re: VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Re: commit so slow program looks frozen
  • From: Merlin Moncure
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: VACUUMs take twice as long across all nodes
  • From: Tom Lane
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: commit so slow program looks frozen
  • From: Rocco Altier
• Re: commit so slow program looks frozen
  • From: Magnus Hagander
• VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Re: commit so slow program looks frozen
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: commit so slow program looks frozen
  • From: Joshua D. Drake
• Re: commit so slow program looks frozen
  • From: Scott Marlowe
• Re: Configuration Issue ?
  • From: Joshua D. Drake
• Re: Configuration Issue ?
  • From: Mark Lonsdale
• Re: Configuration Issue ?
  • From: Joshua D. Drake
• Re: Configuration Issue ?
  • From: Richard Huxton
• Re: Configuration Issue ?
  • From: Mark Lonsdale
• Re: commit so slow program looks frozen
  • From: Brian Hurt
• Re: Configuration Issue ?
  • From: Joshua D. Drake
• Configuration Issue ?
  • From: Mark Lonsdale
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: Best COPY Performance
  • From: Markus Schaber
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: commit so slow program looks frozen
  • From: Alvaro Herrera
• Re: ACCESS EXCLUSIVE lock
  • From: Atesz
• Re: Best COPY Performance
  • From: Craig A. James
• query slows down drastically with increased number of fields
  • From: Tom Darci
• Re: Best COPY Performance
  • From: Spiegelberg, Greg
• Re: Best COPY Performance
  • From: Craig A. James
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Worky Workerson
• commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: Best COPY Performance
  • From: Merlin Moncure
• Re: Problems using a function in a where clause
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Merlin Moncure
• Re: Best COPY Performance
  • From: Markus Schaber
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Alex Stapleton
• Re: Best COPY Performance
  • From: Craig A. James
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Copy database performance issue
  • From: Jim C. Nasby
• Re: Problems using a function in a where clause
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: Is ODBC that slow?
  • From: Carlo Stonebanks
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Optimizing disk throughput on quad Opteron
  • From: Bucky Jordan
• Re: Copy database performance issue
  • From: Jignesh Shah
• Re: Index on two columns not used
  • From: Markus Schaber
• Re: Slow functional indexes?
  • From: Stuart Bishop
• Re: Index on two columns not used
  • From: Péter Kovács
• Re: Best COPY Performance
  • From: Craig A. James
• Copy database performance issue
  • From: Steve
• Re: Best COPY Performance
  • From: Joshua D. Drake
• Re: Optimizing disk throughput on quad Opteron
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: New hardware thoughts
  • From: Jim C. Nasby
• Re: Vacuum and Memory Loss
  • From: Jim C. Nasby
• Re: New hardware thoughts
  • From: Joshua D. Drake
• Re: New hardware thoughts
  • From: Vivek Khera
• Re: Optimizing disk throughput on quad Opteron
  • From: Joshua D. Drake
• Re: Optimizing disk throughput on quad Opteron
  • From: Vivek Khera
• Re: New hardware thoughts
  • From: Joshua D. Drake
• Re: New hardware thoughts
  • From: Vivek Khera
• Re: Optimizing disk throughput on quad Opteron
  • From: Joshua D. Drake
• Re: Optimizing disk throughput on quad Opteron
  • From: Vivek Khera
• Re: New hardware thoughts
  • From: Bucky Jordan
• Problems using a function in a where clause
  • From: Mara Dalponte
• Re: Index on two columns not used
  • From: Tom Lane
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Index on two columns not used
  • From: Markus Schaber
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Index on two columns not used
  • From: Alvaro Herrera
• Re: Index on two columns not used
  • From: Markus Schaber
• Re: Optimizing disk throughput on quad Opteron
  • From: John Philips
• Re: Best COPY Performance
  • From: Markus Schaber
• Re: Vacuum and Memory Loss
  • From: Richard Huxton
• Re: New hardware thoughts
  • From: Arjen van der Meijden
• Re: New hardware thoughts
  • From: Joshua D. Drake
• Re: New hardware thoughts
  • From: Arjen van der Meijden
• Re: pgBench on Windows
  • From: Harald Armin Massa
• Re: Vacuum and Memory Loss
  • From: Dave Dutcher
• Re: New hardware thoughts
  • From: Bucky Jordan
• Re: Jdbc/postgres performance
  • From: Dave Cramer
• Re: Optimizing disk throughput on quad Opteron
  • From: Ben Suffolk
• Re: Optimizing disk throughput on quad Opteron
  • From: Joshua D. Drake
• Re: Is ODBC that slow?
  • From: Joshua D. Drake
• Re: Is ODBC that slow?
  • From: Alvaro Herrera
• Optimizing disk throughput on quad Opteron
  • From: John Philips
• Re: Is ODBC that slow?
  • From: Carlo Stonebanks
• Re: pgBench on Windows
  • From: Magnus Hagander
• Re: Index on two columns not used
  • From: Péter Kovács
• Re: VACUUM Performance
  • From: Tom Lane
• Re: Is ODBC that slow?
  • From: Joshua D. Drake
• Re: Is ODBC that slow?
  • From: Joshua D. Drake
• Re: Slow functional indexes?
  • From: Tom Lane
• Re: Is ODBC that slow?
  • From: Merlin Moncure
• Re: Slow functional indexes?
  • From: Merlin Moncure
• Re: Is ODBC that slow?
  • From: Alvaro Herrera
• Re: Best COPY Performance
  • From: Merlin Moncure
• Re: Is ODBC that slow?
  • From: Merlin Moncure
• Is ODBC that slow?
  • From: Carlo Stonebanks
• VACUUM Performance
  • From: Steve Oualline
• [no subject]
  • From: Unknown
• [no subject]
  • From: Unknown
• Re: New hardware thoughts
  • From: alvis
• Re: New hardware thoughts
  • From: Ben Suffolk
• Best COPY Performance
  • From: Worky Workerson
• Re: New hardware thoughts
  • From: Joshua D. Drake
• Re: New hardware thoughts
  • From: Ben Suffolk
• Re: New hardware thoughts
  • From: Ben Suffolk
• Re: New hardware thoughts
  • From: Dave Cramer
• Re: New hardware thoughts
  • From: Shane Ambler
• Re: measuring shared memory usage on Windows
  • From: David Boreham
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: VACUUM FULL ANALYZE on 8.1.4 is slower then on 8.0
  • From: Markus Schaber
• pgBench on Windows
  • From: Harald Armin Massa
• Re: measuring shared memory usage on Windows
  • From: Harald Armin Massa
• Re: measuring shared memory usage on Windows
  • From: Harald Armin Massa
• New hardware thoughts
  • From: Ben Suffolk
• Slow functional indexes?
  • From: Stuart Bishop
• Vacuum and Memory Loss
  • From: Mike
• Re: Swappiness setting on a linux pg server
  • From: Kevin
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Merlin Moncure
• Re: Swappiness setting on a linux pg server
  • From: Ron
• Re: DB Performance decreases due to often written/accessed table
  • From: Merlin Moncure
• Re: DB Performance decreases due to often written/accessed table
  • From: Jens Schipkowski
• Re: DB Performance decreases due to often written/accessed
  • From: Richard Huxton
• Re: DB Performance decreases due to often written/accessed table
  • From: Merlin Moncure
• Re: DB Performance decreases due to often written/accessed
  • From: Jim C. Nasby
• Re: DB Performance decreases due to often written/accessed
  • From: Richard Huxton
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: DB Performance decreases due to often written/accessed table
  • From: Jens Schipkowski
• Re: Swappiness setting on a linux pg server
  • From: Jim C. Nasby
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Jim C. Nasby
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Jim C. Nasby
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Jim C. Nasby
• Re: DB Performance decreases due to often written/accessed
  • From: Richard Huxton
• Re: VACUUM FULL ANALYZE on 8.1.4 is slower then on 8.0
  • From: Tom Lane
• Re: VACUUM FULL ANALYZE on 8.1.4 is slower then on 8.0
  • From: Michael Fuhr
• Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: ACCESS EXCLUSIVE lock
  • From: Atesz
• VACUUM FULL ANALYZE on 8.1.4 is slower then on 8.0
  • From: Andrzej Zawadzki
• DB Performance decreases due to often written/accessed table
  • From: Jens Schipkowski
• [no subject]
  • From: Rohit_Behl
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Ioana Danes
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Ioana Danes
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Ioana Danes
• Re: measuring shared memory usage on Windows
  • From: Mark Kirkwood
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jeff Davis
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Tom Lane
• Re: index growth problem
  • From: Tom Lane
• Re: index growth problem
  • From: Jim C. Nasby
• Re: index growth problem
  • From: Graham Davis
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jim C. Nasby
• Re: index growth problem
  • From: Jim C. Nasby
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jeff Davis
• index growth problem
  • From: Graham Davis
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jim C. Nasby
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jeff Davis
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Dimitri Fontaine
• Re: [GENERAL] UDF and cache
  • From: Jim C. Nasby
• Re: [HACKERS] UDF and cache
  • From: Jim C. Nasby
• UDF and cache
  • From: jungmin shin
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jeff Davis
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Ioana Danes
• Re: [ADMIN] autovacuum on a -mostly- r/o table
  • From: Larry Rosenman
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Ioana Danes
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Joshua Marsh
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Dimitri Fontaine
• Postgresql 8.1.4 - performance issues for select on view using max
  • From: Ioana Danes
• Re: Optimization of this SQL sentence
  • From: Merlin Moncure
• Re: Optimization of this SQL sentence (SOLVED)
  • From: Jim C. Nasby
• Re: Optimization of this SQL sentence
  • From: Jim C. Nasby
• Re: [ADMIN] autovacuum on a -mostly- r/o table
  • From: Jim C. Nasby
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Jim C. Nasby
• Re: Index on two columns not used
  • From: Arnaud Lesauvage
• Re: Index on two columns not used
  • From: Tom Lane
• Re: Hints proposal
  • From: Robert Treat
• Re: ACCESS EXCLUSIVE lock
  • From: Tom Lane
• Re: ACCESS EXCLUSIVE lock
  • From: Scott Marlowe
• Re: Index on two columns not used
  • From: Arnaud Lesauvage
• ACCESS EXCLUSIVE lock
  • From: Atesz
• Re: Index on two columns not used
  • From: Heikki Linnakangas
• Re: Index on two columns not used
  • From: Arnaud Lesauvage
• Re: Index on two columns not used
  • From: Heikki Linnakangas
• Re: Jdbc/postgres performance
  • From: Merlin Moncure
• Re: Jdbc/postgres performance
  • From: Merlin Moncure
• Re: Jdbc/postgres performance
  • From: Heikki Linnakangas
• Re: Optimization of this SQL sentence
  • From: mark
• Re: Index on two columns not used
  • From: Arnaud Lesauvage
• Re: Jdbc/postgres performance
  • From: Rohit_Behl
• Re: Jdbc/postgres performance
  • From: Rohit_Behl
• Re: Index on two columns not used
  • From: Heikki Linnakangas
• Index on two columns not used
  • From: Arnaud Lesauvage
• Re: Optimization of this SQL sentence
  • From: Mark Kirkwood
• Re: Optimization of this SQL sentence
  • From: Mario Weilguni
• Re: Optimization of this SQL sentence
  • From: Ruben Rubio
• Re: Jdbc/postgres performance
  • From: Tom Lane
• Re: Jdbc/postgres performance
  • From: Merlin Moncure
• Re: Hints proposal
  • From: Tom Lane
• Re: Optimization of this SQL sentence
  • From: Craig A. James
• Re: Hints proposal
  • From: Robert Treat
• Re: [HACKERS] Hints proposal
  • From: Robert Treat
• Re: Jdbc/postgres performance
  • From: Bucky Jordan
• Re: Jdbc/postgres performance
  • From: Merlin Moncure
• Jdbc/postgres performance
  • From: Rohit_Behl
• Re: Optimization of this SQL sentence
  • From: Shane Ambler
• Re: Optimization of this SQL sentence
  • From: Christopher Browne
• Jdbc/postgres performance
  • From: Behl, Rohit (Infosys)
• Re: Optimization of this SQL sentence
  • From: Shane Ambler
• Re: Optimization of this SQL sentence
  • From: Chris Browne
• Re: Optimization of this SQL sentence
  • From: Chris Browne
• Re: Optimization of this SQL sentence
  • From: Merlin Moncure
• Re: Optimization of this SQL sentence
  • From: Mario Weilguni
• Re: Optimization of this SQL sentence
  • From: Alexander Staubo
• Re: Optimization of this SQL sentence
  • From: Alexander Staubo
• Re: Optimization of this SQL sentence
  • From: Craig A. James
• Re: Regarding Bitmap Scan
  • From: Dawid Kuroczko
• Re: Regarding Bitmap Scan
  • From: A. Kretschmer
• Regarding Bitmap Scan
  • From: soni de
• Re: Optimization of this SQL sentence (SOLVED)
  • From: Ruben Rubio
• Re: Optimization of this SQL sentence
  • From: Heikki Linnakangas
• Re: Optimization of this SQL sentence
  • From: Alexander Staubo
• Re: Optimization of this SQL sentence
  • From: A. Kretschmer
• Re: Optimization of this SQL sentence
  • From: Ruben Rubio
• Re: Optimization of this SQL sentence
  • From: Ruben Rubio
• Re: Optimization of this SQL sentence
  • From: Gregory S. Williamson
• Optimization of this SQL sentence
  • From: Ruben Rubio
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Shaun Thomas
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Merlin Moncure
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Jim C. Nasby
• Re: measuring shared memory usage on Windows
  • From: Harald Armin Massa
• Re: Hints proposal
  • From: Mark Kirkwood
• measuring shared memory usage on Windows
  • From: Harald Armin Massa
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Hints proposal
  • From: Shaun Thomas
• Re: Hints proposal
  • From: Bruce Momjian
• Re: Hints proposal
  • From: Brian Hurt
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Merlin Moncure
• Re: Hints proposal
  • From: Csaba Nagy
• Re: measuring shared memory usage on Windows
  • From: David Boreham
• Re: measuring shared memory usage on Windows
  • From: David Boreham
• Re: Hints proposal
  • From: Mark Kirkwood
• Re: measuring shared memory usage on Windows
  • From: Magnus Hagander
• Re: measuring shared memory usage on Windows
  • From: Harald Armin Massa
• Re: measuring shared memory usage on Windows
  • From: Magnus Hagander
• Re: measuring shared memory usage on Windows
  • From: Harald Armin Massa
• Re: Hints proposal
  • From: mark
• Re: measuring shared memory usage on Windows
  • From: Magnus Hagander
• measuring shared memory usage on Windows
  • From: Harald Armin Massa
• Re: Hints proposal
  • From: Craig A. James
• Re: Hints proposal
  • From: Craig A. James
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Tom Lane
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: [ADMIN] autovacuum on a -mostly- r/o table
  • From: Tobias Brox
• Re: [ADMIN] autovacuum on a -mostly- r/o table
  • From: Matthew T. O'Connor
• Re: [ADMIN] autovacuum on a -mostly- r/o table
  • From: Tobias Brox
• Re: [HACKERS] Hints proposal
  • From: Mischa Sandberg
• Re: [HACKERS] Hints proposal
  • From: Tom Lane
• Re: [HACKERS] Hints proposal
  • From: Alvaro Herrera
• Re: [HACKERS] Hints proposal
  • From: Jim C. Nasby
• Re: [HACKERS] Hints proposal
  • From: Josh Berkus
• Re: [HACKERS] Hints proposal
  • From: Josh Berkus
• Re: [HACKERS] Hints proposal
  • From: Bucky Jordan
• Re: [HACKERS] Hints proposal
  • From: Gregory Stark
• Re: [HACKERS] Hints proposal
  • From: Tom Lane
• Re: [HACKERS] Hints proposal
  • From: Jim C. Nasby
• Re: [HACKERS] Hints proposal
  • From: Zeugswetter Andreas ADI SD
• Re: Hints proposal
  • From: Christopher Browne
• Re: Hints proposal
  • From: Jeff Davis
• Re: FW: Simple join optimized badly?
  • From: Mark Kirkwood
• Re: Hints proposal
  • From: Jeff Davis
• Re: FW: Simple join optimized badly?
  • From: Mark Kirkwood
• Re: [HACKERS] Hints proposal
  • From: Alvaro Herrera
• Re: Hints proposal
  • From: Richard Broersma Jr
• Re: Hints proposal
  • From: Tom Lane
• Re: [HACKERS] Hints proposal
  • From: Bucky Jordan
• Re: Hints proposal
  • From: Arjen van der Meijden
• Re: [HACKERS] Hints proposal
  • From: Josh Berkus
• Re: Hints proposal
  • From: Jim C. Nasby
• Re: [HACKERS] Hints proposal
  • From: Jim C. Nasby
• Re: Hints proposal
  • From: Jeff Davis
• Re: [HACKERS] Hints proposal
  • From: Andrew Sullivan
• Re: Scrub one large table against another
  • From: Tom Lane
• Re: Scrub one large table against another
  • From: Brendan Curran
• Re: FW: Simple join optimized badly?
  • From: Scott Marlowe
• Re: Hints proposal
  • From: Csaba Nagy
• Re: [HACKERS] Hints proposal
  • From: Tom Lane
• Re: [HACKERS] Hints proposal
  • From: Csaba Nagy
• Re: Hints proposal
  • From: Jim C. Nasby
• Re: Hints proposal
  • From: Jim C. Nasby
• Re: [HACKERS] Hints proposal
  • From: Josh Berkus
• Re: Hints proposal
  • From: Jeff Davis
• Re: [HACKERS] Hints proposal
  • From: Josh Berkus
• Re: Hints proposal
  • From: Bucky Jordan
• Re: FW: Simple join optimized badly?
  • From: Jim C. Nasby
• Re: Hints proposal
  • From: Csaba Nagy
• Re: [HACKERS] Hints proposal
  • From: Jim C. Nasby
• Re: Hints proposal
  • From: Tom Lane
• Re: Hints proposal
  • From: Merlin Moncure
• Re: Hints proposal
  • From: Heikki Linnakangas
• Re: Hints proposal
  • From: Tom Lane
• Re: Hints proposal
  • From: Joshua Marsh
• Re: Hints proposal
  • From: Bruce Momjian
• Hints proposal
  • From: Jim C. Nasby
• Re: FW: Simple join optimized badly?
  • From: Tom Lane
• Re: FW: Simple join optimized badly?
  • From: Jim C. Nasby
• Re: FW: Simple join optimized badly?
  • From: Mark Kirkwood
• FW: Simple join optimized badly?
  • From: H.J. Sanders
• Re: Scrub one large table against another (vmstat output)
  • From: Markus Schaber
• Re: Scrub one large table against another
  • From: Jim C. Nasby
• Collect stats during seqscan (was: Simple join optimized badly?)
  • From: Jim C. Nasby
• Re: Scrub one large table against another (vmstat output)
  • From: Brendan Curran
• Re: Scrub one large table against another
  • From: Brendan Curran
• Re: Simple join optimized badly?
  • From: Mark Lewis
• Re: Simple join optimized badly?
  • From: Bruce Momjian
• Re: Simple join optimized badly?
  • From: Heikki Linnakangas
• Re: Simple join optimized badly?
  • From: Bucky Jordan
• Re: Simple join optimized badly?
  • From: Brian Herlihy
• Re: Scrub one large table against another
  • From: Tom Lane
• Re: Simple join optimized badly?
  • From: Tom Lane
• Re: Simple join optimized badly?
  • From: Brian Herlihy
• Re: Scrub one large table against another
  • From: Jim C. Nasby
• Re: Simple join optimized badly?
  • From: Mark Kirkwood
• Re: Simple join optimized badly?
  • From: Mark Kirkwood
• Re: Scrub one large table against another
  • From: Brendan Curran
• Re: Scrub one large table against another
  • From: Tom Lane
• Re: Scrub one large table against another
  • From: Brendan Curran
• Re: Scrub one large table against another
  • From: Tom Lane
• Scrub one large table against another
  • From: Brendan Curran
• Re: Simple join optimized badly?
  • From: Jim C. Nasby
• Re: long running transactions
  • From: Tobias Brox
• Re: long running transactions
  • From: Tom Lane
• Re: long running transactions
  • From: Tobias Brox
• Re: long running transactions
  • From: Tom Lane
• Re: long running transactions
  • From: Tobias Brox
• Re: Simple join optimized badly?
  • From: Josh Berkus
• Re: long running transactions
  • From: Tom Lane
• Re: long running transactions
  • From: Tobias Brox
• Re: long running transactions
  • From: Tom Lane
• Re: long running transactions
  • From: Tobias Brox
• Re: long running transactions
  • From: Tom Lane
• Re: long running transactions
  • From: Tobias Brox
• Re: long running transactions
  • From: Tobias Brox
• Re: Simple join optimized badly?
  • From: Bruno Wolff III
• Re: long running transactions
  • From: Tom Lane
• long running transactions
  • From: Tobias Brox
• Re: Simple join optimized badly?
  • From: Joshua D. Drake
• Re: Simple join optimized badly?
  • From: Joshua D. Drake
• Re: Simple join optimized badly?
  • From: Joshua D. Drake
• Re: Simple join optimized badly?
  • From: Jim C. Nasby
• Re: Simple join optimized badly?
  • From: Steinar H. Gunderson
• Re: Postgre 8.0 Installation - Issues
  • From: Jim C. Nasby
• Re: Simple join optimized badly?
  • From: Tom Lane
• Re: Simple join optimized badly?
  • From: Jim C. Nasby
• Re: Simple join optimized badly?
  • From: Jim C. Nasby
• Re: Simple join optimized badly?
  • From: Jim C. Nasby
• Postgre 8.0 Installation - Issues
  • From: Ravindran G - TLS, Chennai.
• Re: odd variances in count(*) times
  • From: Merlin Moncure
• Re: Simple join optimized badly?
  • From: Joshua D. Drake
• Re: Simple join optimized badly?
  • From: Craig A. James
• Re: Simple join optimized badly?
  • From: Brian Herlihy
• Re: Simple join optimized badly?
  • From: Tom Lane
• Re: Simple join optimized badly?
  • From: Joshua D. Drake
• Re: Simple join optimized badly?
  • From: Tom Lane
• Re: Simple join optimized badly?
  • From: Jim C. Nasby
• Re: Simple join optimized badly?
  • From: Tobias Brox
• Re: autovacuum not working?
  • From: Jim C. Nasby
• Re: odd variances in count(*) times
  • From: Jim C. Nasby
• Re: Simple join optimized badly?
  • From: Jim C. Nasby
• Re: Simple join optimized badly?
  • From: Scott Marlowe
• Re: Simple join optimized badly?
  • From: Chris Browne
• Re: odd variances in count(*) times
  • From: Steinar H. Gunderson
• Re: odd variances in count(*) times
  • From: Merlin Moncure
• Re: odd variances in count(*) times
  • From: Stephen Frost
• odd variances in count(*) times
  • From: Merlin Moncure
• Re: Simple join optimized badly?
  • From: Tom Lane
• Re: Simple join optimized badly?
  • From: Josh Berkus
• Re: autovacuum not working?
  • From: Medora Schauer
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Merlin Moncure
• Re: autovacuum not working?
  • From: Bill Moran
• autovacuum not working?
  • From: Medora Schauer
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Merlin Moncure
• Re: Simple join optimized badly?
  • From: Tom Lane
• Re: Simple join optimized badly?
  • From: Mark Kirkwood
• Re: Simple join optimized badly?
  • From: Chris Browne
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Jim C. Nasby
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Jim C. Nasby
• Re: Simple join optimized badly?
  • From: Craig A. James
• Re: Simple join optimized badly?
  • From: Craig A. James
• Re: Simple join optimized badly?
  • From: Mark Kirkwood
• Re: Simple join optimized badly?
  • From: Bruce Momjian
• Re: Simple join optimized badly?
  • From: Tom Lane
• Re: Simple join optimized badly?
  • From: Craig A. James
• Re: Simple join optimized badly?
  • From: Josh Berkus
• Re: Simple join optimized badly?
  • From: Jim Nasby
• Re: Simple join optimized badly?
  • From: Denis Lussier
• Re: Simple join optimized badly?
  • From: Tom Lane
• Simple join optimized badly?
  • From: Craig A. James
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Merlin Moncure
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Scott Marlowe
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: slow queue-like empty table
  • From: Jim Nasby
• Re: Unsubscribe
  • From: Jim Nasby
• Re: Unsubscribe
  • From: Jim Nasby
• Re: Unsubscribe
  • From: Jim Nasby
• Re: any hope for my big query?
  • From: Jim Nasby
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Tom Lane
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Merlin Moncure
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Tom Lane
• Re: UPDATE becomes mired / win32
  • From: Tom Lane
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Merlin Moncure
• Re: UPDATE becomes mired / win32
  • From: Steve Peterson
• Re: UPDATE becomes mired / win32
  • From: Steve Peterson
• Re: pg_trgm indexes giving bad estimations?
  • From: Tom Lane
• pg_trgm indexes giving bad estimations?
  • From: Ben
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: any hope for my big query?
  • From: Ben
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Merlin Moncure
• Re: Multi-key index not beeing used - bug?
  • From: Tobias Brox
• Re: Multi-key index not beeing used - bug?
  • From: Tom Lane
• Re: UPDATE becomes mired / win32
  • From: Tom Lane
• Re: Unsubscribe
  • From: Michael Stone
• Re: Multi-key index not beeing used - bug?
  • From: Graham Davis
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: UPDATE becomes mired / win32
  • From: me
• Multi-key index not beeing used - bug?
  • From: Tobias Brox
• UPDATE becomes mired / win32
  • From: Steve Peterson
• Re: Poor performance on very simple query ?
  • From: Markus Schaber
• Re: Unsubscribe
  • From: Geoffrey
• Re: Unsubscribe
  • From: Steve Atkins
• Re: Unsubscribe
  • From: Csaba Nagy
• Re: Unsubscribe
  • From: Mark Lewis
• Re: Unsubscribe
  • From: Joshua D. Drake
• Re: Unsubscribe
  • From: Joshua D. Drake
• Re: Unsubscribe
  • From: D'Arcy J.M. Cain
• Re: Unsubscribe
  • From: Bruno Wolff III
• Re: Unsubscribe
  • From: Csaba Nagy
• Re: Unsubscribe
  • From: Joshua D. Drake
• Re: Unsubscribe
  • From: Joshua D. Drake
• Re: Unsubscribe
  • From: Nolan Cafferky
• Re: Unsubscribe
  • From: Tobias Brox
• Re: Unsubscribe
  • From: Joshua D. Drake
• Re: Unsubscribe
  • From: Bruno Wolff III
• Re: simple case using index on windows but not on linux
  • From: simon godden
• Re: simple case using index on windows but not on linux
  • From: simon godden
• Re: simple case using index on windows but not on linux
  • From: Dave Dutcher
• Re: simple case using index on windows but not on linux
  • From: Richard Huxton
• Re: PostgreSQL Caching
  • From: Brad Nicholson
• Re: simple case using index on windows but not on linux
  • From: simon godden
• Re: PostgreSQL Caching
  • From: Brad Nicholson
• Re: simple case using index on windows but not on linux
  • From: Richard Huxton
• Re: PostgreSQL Caching
  • From: Dave Dutcher
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Markus Schaber