Postgres Performance Date Index

• Thread Index

• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Merlin Moncure
• Re: strange performance regression between 7.4 and 8.1
  • From: Ron
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: Identical Queries
  • From: Craig A. James
• Re: performances with Pentium D
  • From: hatman
• Re: Identical Queries
  • From: Stephan Szabo
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: stats collector process high CPU utilization
  • From: Merlin Moncure
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: Identical Queries
  • From: Chad Wagner
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: Identical Queries
  • From: Rob Schall
• Re: strange performance regression between 7.4 and 8.1
  • From: Joshua D. Drake
• strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: Identical Queries
  • From: Stephan Szabo
• Re: increasing database connections
  • From: Joshua D. Drake
• Identical Queries
  • From: Rob Schall
• Performance Query
  • From: Abu Mushayeed
• Re: increasing database connections
  • From: Ron
• Re: increasing database connections
  • From: Florian Weimer
• Re: performances with Pentium D
  • From: Ben Trewern
• Re: increasing database connections
  • From: Magnus Hagander
• Re: increasing database connections
  • From: Mark Kirkwood
• Re: increasing database connections
  • From: Joshua D. Drake
• Re: increasing database connections
  • From: Jonah H. Harris
• increasing database connections
  • From: Shiva Sarna
• Re: Two hard drives --- what to do with them?
  • From: Bruno Wolff III
• Re: Two hard drives --- what to do with them?
  • From: Bruno Wolff III
• Re: Two hard drives --- what to do with them?
  • From: Bruno Wolff III
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Carlos Moreno
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Carlos Moreno
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Rodrigo Gonzalez
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Carlos Moreno
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Carlos Moreno
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Tom Lane
• Upgraded to 8.2.3 --- still having performance issues
  • From: Carlos Moreno
• performances with Pentium D
  • From: hatman
• Re: Writting a "search engine" for a pgsql DB
  • From: Dave Page
• Re: Writting a "search engine" for a pgsql DB
  • From: Oleg Bartunov
• Re: Writting a "search engine" for a pgsql DB
  • From: Dave Page
• Re: Writting a "search engine" for a pgsql DB
  • From: Steinar H. Gunderson
• Re: Writting a "search engine" for a pgsql DB
  • From: Dave Page
• Re: Writting a "search engine" for a pgsql DB
  • From: Magnus Hagander
• Re: Opinions on Raid
  • From: Geoff Tolley
• Re: Writting a "search engine" for a pgsql DB
  • From: Charles Sprickman
• Re: Writting a "search engine" for a pgsql DB
  • From: Chris
• Re: Two hard drives --- what to do with them?
  • From: Scott Marlowe
• Re: Two hard drives --- what to do with them?
  • From: Jeff Davis
• Re: Opinions on Raid
  • From: Scott Marlowe
• Re: [kris@xxxxxxxxxxxxxx: Anyone interested in improving postgresql scaling?]
  • From: Tom Lane
• Re: Two hard drives --- what to do with them?
  • From: Shane Ambler
• Re: Opinions on Raid
  • From: Joe Uhl
• [kris@xxxxxxxxxxxxxx: Anyone interested in improving postgresql scaling?]
  • From: Jim C. Nasby
• [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Jim C. Nasby
• Re: Postgres performance Linux vs FreeBSD
  • From: Andrew - Supernews
• Re: Opinions on Raid
  • From: Scott Marlowe
• Re: Opinions on Raid
  • From: mark
• Insert performance
  • From: hatman
• Re: Opinions on Raid
  • From: Ron
• Re: Two hard drives --- what to do with them?
  • From: Ben
• Re: Opinions on Raid
  • From: Stefan Kaltenbrunner
• Re: Writting a "search engine" for a pgsql DB
  • From: Dave Page
• Opinions on Raid
  • From: Joe Uhl
• Re: Writting a "search engine" for a pgsql DB
  • From: Magnus Hagander
• Re: Two hard drives --- what to do with them?
  • From: Peter Kovacs
• Re: Two hard drives --- what to do with them?
  • From: Shane Ambler
• Re: Two hard drives --- what to do with them?
  • From: Jeff Davis
• Re: Two hard drives --- what to do with them?
  • From: Peter Kovacs
• Re: Two hard drives --- what to do with them?
  • From: Jeff Davis
• Re: Writting a "search engine" for a pgsql DB
  • From: Charles Sprickman
• Re: Vacuumdb - Max_FSM_Pages Problem.
  • From: Ron
• Re: Writting a "search engine" for a pgsql DB
  • From: Jeff Davis
• Re: Writting a "search engine" for a pgsql DB
  • From: Mark Stosberg
• Re: Writting a "search engine" for a pgsql DB
  • From: Madison Kelly
• Re: Writting a "search engine" for a pgsql DB
  • From: Mark Stosberg
• Re: Writting a "search engine" for a pgsql DB
  • From: Magnus Hagander
• Re: Writting a "search engine" for a pgsql DB
  • From: Madison Kelly
• Re: [JDBC] does prepareThreshold work? forced to use old driver
  • From: Gene
• Re: Writting a "search engine" for a pgsql DB
  • From: Joshua D. Drake
• Re: Writting a "search engine" for a pgsql DB
  • From: Mark Stosberg
• Re: [JDBC] does prepareThreshold work? forced to use old driver
  • From: Dave Cramer
• Re: low memory usage reported by 'top' indicates poor tuning?
  • From: Mark Stosberg
• Re: low memory usage reported by 'top' indicates poor tuning?
  • From: Joshua D. Drake
• Re: Writting a "search engine" for a pgsql DB
  • From: Joshua D. Drake
• low memory usage reported by 'top' indicates poor tuning?
  • From: Mark Stosberg
• Re: [JDBC] does prepareThreshold work? forced to use old driver
  • From: Kris Jurka
• Writting a "search engine" for a pgsql DB
  • From: Madison Kelly
• does prepareThreshold work? forced to use old driver
  • From: Gene
• Re: Vacuumdb - Max_FSM_Pages Problem.
  • From: Peter Childs
• Vacuumdb - Max_FSM_Pages Problem.
  • From: Pallav Kalva
• Re: Server Startup Error
  • From: Richard Huxton
• Re: Server Startup Error
  • From: Rodrigo Gonzalez
• Re: Server Startup Error
  • From: Richard Huxton
• Re: Server Startup Error
  • From: Gauri Kanekar
• Re: Server Startup Error
  • From: Rodrigo Gonzalez
• Server Startup Error
  • From: Gauri Kanekar
• Re: pg_trgm performance
  • From: Oleg Bartunov
• Re: pg_trgm performance
  • From: Guillaume Smet
• Re: pg_trgm performance
  • From: Oleg Bartunov
• Re: pg_trgm performance
  • From: Guillaume Smet
• Re: Query Planner
  • From: Steinar H. Gunderson
• Query Planner
  • From: Gauri Kanekar
• Re: Very slow bytea data extraction
  • From: Richard Huxton
• invalid page header in block 428 of relation "pg_attribute"
  • From: ashok@xxxxxxxxxxxxx
• Re: Two hard drives --- what to do with them?
  • From: Peter Kovacs
• Re: Two hard drives --- what to do with them?
  • From: Alexander Staubo
• Re: Two hard drives --- what to do with them?
  • From: Tom Lane
• Two hard drives --- what to do with them?
  • From: Carlos Moreno
• Re: which Xeon processors don't have the context switching problem
  • From: Joshua D. Drake
• Re: pg_trgm performance
  • From: Steinar H. Gunderson
• Re: which Xeon processors don't have the context switching problem
  • From: Geoffrey
• Re: pg_trgm performance
  • From: Guillaume Smet
• Re: which Xeon processors don't have the context switching problem
  • From: Magnus Hagander
• Re: pg_trgm performance
  • From: Steinar H. Gunderson
• Re: pg_trgm performance
  • From: Guillaume Smet
• Re: long checkpoint_timeout
  • From: Jim C. Nasby
• Re: which Xeon processors don't have the context switching problem
  • From: Guillaume Smet
• Re: which Xeon processors don't have the context switching problem
  • From: Guillaume Smet
• Re: which Xeon processors don't have the context switching problem
  • From: Geoffrey
• Re: which Xeon processors don't have the context switching problem
  • From: Joshua D. Drake
• Re: which Xeon processors don't have the context switching problem
  • From: Geoffrey
• Re: which Xeon processors don't have the context switching problem
  • From: Josh Berkus
• Re: long checkpoint_timeout
  • From: Jeff Davis
• Re: long checkpoint_timeout
  • From: Jim C. Nasby
• Re: which Xeon processors don't have the context switching problem
  • From: Steinar H. Gunderson
• Re: which Xeon processors don't have the context switching problem
  • From: Alvaro Herrera
• Re: which Xeon processors don't have the context switching problem
  • From: Steinar H. Gunderson
• Re: which Xeon processors don't have the context switching problem
  • From: Claus Guttesen
• which Xeon processors don't have the context switching problem
  • From: Geoffrey
• long checkpoint_timeout
  • From: Jeff Davis
• Re: Recommended Initial Settings
  • From: Bill Moran
• Re: Very slow bytea data extraction
  • From: msmbarabino@xxxxxxxxxxx
• Re: Very slow bytea data extraction
  • From: msmbarabino@xxxxxxxxxxx
• Re: Recommended Initial Settings
  • From: Jim C. Nasby
• Re: Using the 8.2 autovacuum values with 8.1
  • From: Jim C. Nasby
• Re: Recommended Initial Settings
  • From: Richard Huxton
• Re: Recommended Initial Settings
  • From: Campbell, Lance
• Re: R: Very slow bytea data extraction
  • From: Merlin Moncure
• Re: Recommended Initial Settings
  • From: Richard Huxton
• Recommended Initial Settings
  • From: Campbell, Lance
• Re: R: Very slow bytea data extraction
  • From: Richard Huxton
• R: Very slow bytea data extraction
  • From: msmbarabino@xxxxxxxxxxx
• Re: Very slow bytea data extraction
  • From: Richard Huxton
• Very slow bytea data extraction
  • From: msmbarabino@xxxxxxxxxxx
• Re: Using the 8.2 autovacuum values with 8.1
  • From: Csaba Nagy
• Re: slow update on 1M rows (worse with indexes)
  • From: ismo . tuononen
• Using the 8.2 autovacuum values with 8.1
  • From: Mark Stosberg
• Re: Vacuum full very slow due to nonremovable dead rows...What makes the dead rows non-removable?
  • From: Steinar H. Gunderson
• Vacuum full very slow due to nonremovable dead rows...What makes the dead rows non-removable?
  • From: Barbara Cosentino
• Re: slow update on 1M rows (worse with indexes)
  • From: Joshua D. Drake
• Re: slow update on 1M rows (worse with indexes)
  • From: Steinar H. Gunderson
• slow update on 1M rows (worse with indexes)
  • From: Gabriel Biberian
• Re: Disable result buffering to frontend clients
  • From: Richard Huxton
• Disable result buffering to frontend clients
  • From: Konstantinos Krikellas
• Re: How to avoid vacuuming a huge logging table
  • From: D'Arcy J.M. Cain
• Re: How to avoid vacuuming a huge logging table
  • From: Greg Sabino Mullane
• Re: General advice on user functions
  • From: Dan Harris
• Re: Postgres performance Linux vs FreeBSD
  • From: Mark Kirkwood
• Re: Auto-Vacuum in 8.1 was ineffective for me. 8.2 may work better?
  • From: Alvaro Herrera
• Re: Auto-Vacuum in 8.1 was ineffective for me. 8.2 may work better?
  • From: Matthew T. O'Connor
• Re: Auto-Vacuum in 8.1 was ineffective for me. 8.2 may work better?
  • From: Mark Stosberg
• Re: General advice on user functions
  • From: Albert Cervera Areny
• Re: General advice on user functions
  • From: Merlin Moncure
• Re: Postgres performance Linux vs FreeBSD
  • From: Dimitri Fontaine
• Re: How to avoid vacuuming a huge logging table
  • From: Greg Sabino Mullane
• Re: Auto-Vacuum in 8.1 was ineffective for me. 8.2 may work better?
  • From: Alvaro Herrera
• Auto-Vacuum in 8.1 was ineffective for me. 8.2 may work better?
  • From: Mark Stosberg
• General advice on user functions
  • From: Dan Harris
• How to avoid vacuuming a huge logging table
  • From: Mark Stosberg
• Re: How to debug performance problems
  • From: Mark Stosberg
• Re: How to debug performance problems
  • From: Ray Stell
• Re: How to debug performance problems
  • From: Craig A. James
• Re: How to debug performance problems
  • From: Ray Stell
• Re: Postgres performance Linux vs FreeBSD
  • From: Bill Moran
• Re: Postgres performance Linux vs FreeBSD
  • From: Merlin Moncure
• Postgres performance Linux vs FreeBSD
  • From: Jacek Zaręba
• Re: slow subselects
  • From: Marko Niinimaki
• Re: SELECT performance problem
  • From: Dave Dutcher
• Re: SELECT performance problem
  • From: Jeff Frost
• SELECT performance problem
  • From: Glenn Sullivan
• Re: Query Optimization
  • From: Jim C. Nasby
• Re: slow subselects
  • From: Tom Lane
• Re: slow subselects
  • From: ismo . tuononen
• slow subselects
  • From: Marko Niinimaki
• Re: Query Optimization
  • From: Tom Lane
• Re: How to debug performance problems
  • From: Scott Marlowe
• Re: How to debug performance problems
  • From: Jeff Davis
• Re: How to debug performance problems
  • From: Craig A. James
• Query Optimization
  • From: Reinhard Vicinus
• How to debug performance problems
  • From: Andreas Tille
• Re: Not Picking Index
  • From: Tom Lane
• Re: reindex vs 'analyze'
  • From: Mark Stosberg
• Re: Not Picking Index
  • From: George Pavlov
• Re: Not Picking Index
  • From: Steinar H. Gunderson
• Re: Proximity query with GIST and row estimation
  • From: Guillaume Smet
• Re: Not Picking Index
  • From: Brad Nicholson
• Fwd: Not Picking Index
  • From: Mike Gargano
• Re: Not Picking Index
  • From: Tom Lane
• Re: Not Picking Index
  • From: Alvaro Herrera
• Re: Not Picking Index
  • From: Gauri Kanekar
• Re: Not Picking Index
  • From: Michael Fuhr
• Not Picking Index
  • From: Gauri Kanekar
• Re: Benchmarking PGSQL?
  • From: Krishna Kumar
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Guillaume Smet
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Guillaume Smet
• strange issue for certain queries
  • From: Mike Gargano
• Re: Slow query with 'or' clause
  • From: philippe
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Tom Lane
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Alvaro Herrera
• Re: Proximity query with GIST and row estimation
  • From: Guillaume Smet
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Guillaume Smet
• Re: Slow query with 'or' clause
  • From: Richard Huxton
• Slow query with 'or' clause
  • From: philippe
• Re: Problem with joining queries.
  • From: Konstantinos Krikellas
• Re: Problem with joining queries.
  • From: Richard Huxton
• Re: Benchmarking PGSQL?
  • From: Merlin Moncure
• Problem with joining queries.
  • From: Konstantinos Krikellas
• Re: An unwanted seqscan
  • From: Brian Herlihy
• Re: Benchmarking PGSQL?
  • From: Josh Berkus
• Re: Proximity query with GIST and row estimation
  • From: Paul Ramsey
• Re: How long should it take to insert 200,000 records?
  • From: Lou O'Quin
• Re: JOIN to a VIEW makes a real slow query
  • From: Chuck D.
• Re: reindex vs 'analyze'
  • From: Mark Stosberg
• Re: quad or dual core Intel CPUs
  • From: Claus Guttesen
• Re: Benchmarking PGSQL?
  • From: Luke Lonergan
• Re: Proximity query with GIST and row estimation
  • From: Guillaume Smet
• Re: reindex vs 'analyze' (was: Re: cube operations slower than geo_distance() on production server)
  • From: Tom Lane
• Re: quad or dual core Intel CPUs
  • From: Kenji Morishige
• reindex vs 'analyze' (was: Re: cube operations slower than geo_distance() on production server)
  • From: Mark Stosberg
• Re: Benchmarking PGSQL?
  • From: Merlin Moncure
• Re: Benchmarking PGSQL?
  • From: Luke Lonergan
• Re: cube operations slower than geo_distance() on production server
  • From: Merlin Moncure
• Re: Benchmarking PGSQL?
  • From: Shoaib Mir
• Benchmarking PGSQL?
  • From: Krishna Kumar
• Re: quad or dual core Intel CPUs
  • From: Claus Guttesen
• Re: An unwanted seqscan
  • From: Tom Lane
• An unwanted seqscan
  • From: Brian Herlihy
• Re: cube operations slower than geo_distance() on production server
  • From: Tom Lane
• Re: quad or dual core Intel CPUs
  • From: Heikki Linnakangas
• Re: quad or dual core Intel CPUs
  • From: Guillaume Smet
• Re: quad or dual core Intel CPUs
  • From: Dan Harris
• Re: quad or dual core Intel CPUs
  • From: Mark Kirkwood
• Re: quad or dual core Intel CPUs
  • From: Arjen van der Meijden
• Re: cube operations slower than geo_distance() on production server
  • From: Mark Stosberg
• Re: JOIN to a VIEW makes a real slow query
  • From: Tom Lane
• Re: JOIN to a VIEW makes a real slow query
  • From: Chuck D.
• quad or dual core Intel CPUs
  • From: Kenji Morishige
• Re: JOIN to a VIEW makes a real slow query
  • From: Merlin Moncure
• JOIN to a VIEW makes a real slow query
  • From: Chuck D.
• Re: CPU Usage
  • From: Alan Hodgson
• CPU Usage
  • From: Campbell, Lance
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Tom Lane
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Guillaume Smet
• Proximity query with GIST and row estimation
  • From: Guillaume Smet
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Tom Lane
• Question about Bitmap Heap Scan/BitmapAnd
  • From: Guillaume Smet
• Re: cube operations slower than geo_distance() on production server
  • From: Merlin Moncure
• Re: cube operations slower than geo_distance() on production server
  • From: Merlin Moncure
• Re: many instances or many databases or many users?
  • From: Heikki Linnakangas
• many instances or many databases or many users?
  • From: ismo . tuononen
• Re: limit + order by is slow if no rows in result set
  • From: Tom Lane
• Re: limit + order by is slow if no rows in result set
  • From: Brian Cox
• Re: limit + order by is slow if no rows in result set
  • From: Heikki Linnakangas
• limit + order by is slow if no rows in result set
  • From: Brian Cox
• Re: cube operations slower than geo_distance() on production server
  • From: Mark Stosberg
• Re: cube operations slower than geo_distance() on production server
  • From: Merlin Moncure
• Re: cube operations slower than geo_distance() on production server
  • From: Merlin Moncure
• Re: cube operations slower than geo_distance() on production server
  • From: Mark Stosberg
• Re: cube operations slower than geo_distance() on production server
  • From: Merlin Moncure
• Re: Is there an equivalent for Oracle'suser_tables.num_rows
  • From: Simon Riggs
• Re: Is there an equivalent for Oracle's user_tables.num_rows
  • From: Virag Saksena
• Re: Is there an equivalent for Oracle's user_tables.num_rows
  • From: Tom Lane
• Is there an equivalent for Oracle's user_tables.num_rows
  • From: Virag Saksena
• Re: Can anyone make this code tighter? Too slow, Please help!
  • From: Mark Stosberg
• cube operations slower than geo_distance() on production server
  • From: Mark Stosberg
• Re: Recreate big table
  • From: Daniel Cristian Cruz
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Recreate big table
  • From: Gábriel Ákos
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Alvaro Herrera
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: minshall
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Disk saturation
  • From: Carlos H. Reimer
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: Speed up this query
  • From: Mark Stosberg
• stats collector process high CPU utilization
  • From: Benjamin Minshall
• tip: faster sorting for proximity queries by using cube_distance()
  • From: Mark Stosberg
• Re: Help Needed
  • From: Richard Huxton
• Help Needed
  • From: Muruganantham M
• Re: How long should it take to insert 200,000 records?
  • From: Tom Lane
• Re: How long should it take to insert 200,000 records?
  • From: Mark Kirkwood
• Re: How long should it take to insert 200,000 records?
  • From: Karen Hill
• Re: index scan through a subquery
  • From: Bill Howe
• Re: How long should it take to insert 200,000 records?
  • From: Mark Lewis
• Re: How long should it take to insert 200,000 records?
  • From: Merlin Moncure
• Re: How long should it take to insert 200,000 records?
  • From: Bruno Wolff III
• Re: How long should it take to insert 200,000 records?
  • From: Mark Lewis
• Re: How long should it take to insert 200,000 records?
  • From: Hiltibidal, Robert
• Re: How long should it take to insert 200,000 records?
  • From: Merlin Moncure
• Re: How long should it take to insert 200,000 records?
  • From: Scott Marlowe
• Re: How long should it take to insert 200,000 records?
  • From: Merlin Moncure
• Re: How long should it take to insert 200,000 records?
  • From: Scott Marlowe
• Re: explain analyze output for review (was: optimizing a geo_distance()...)
  • From: Bruno Wolff III
• Re: explain analyze output for review (was: optimizing a geo_distance()...)
  • From: Hiltibidal, Robert
• Re: explain analyze output: vacuuming made a big difference.
  • From: Mark Stosberg
• Re: explain analyze output for review (was: optimizing a geo_distance()...)
  • From: Adam Rich
• Re: explain analyze output for review (was: optimizing a geo_distance()...)
  • From: Hiltibidal, Robert
• Re: explain analyze output for review (was: optimizing a geo_distance()...)
  • From: Mark Stosberg
• Re: optimizing a geo_distance() proximity query (example and benchmark)
  • From: Merlin Moncure
• Re: Tuning
  • From: Harald Armin Massa
• Re: How long should it take to insert 200,000 records?
  • From: Csaba Nagy
• Re: index scan through a subquery
  • From: Tom Lane
• Re: optimizing a geo_distance() proximity query (example and benchmark)
  • From: Bruno Wolff III
• Re: How long should it take to insert 200,000 records?
  • From: Tom Lane
• How long should it take to insert 200,000 records?
  • From: Karen Hill
• Re: optimizing a geo_distance() proximity query (example and benchmark)
  • From: Mark Stosberg
• Re: optimizing a geo_distance() proximity query
  • From: Bruno Wolff III
• Re: optimizing a geo_distance() proximity query
  • From: Merlin Moncure
• Re: optimizing a geo_distance() proximity query
  • From: Mark Stosberg
• Re: trouble with a join on OS X
  • From: Shane Ambler
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: optimizing a geo_distance() proximity query
  • From: Bruno Wolff III
• Re: optimizing a geo_distance() proximity query
  • From: Oleg Bartunov
• optimizing a geo_distance() proximity query
  • From: Mark Stosberg
• Re: trouble with a join on OS X
  • From: Shane Ambler
• Re: trouble with a join on OS X
  • From: Tom Lane
• Re: trouble with a join on OS X
  • From: Joshua D. Drake
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Tom Lane
• Re: trouble with a join on OS X
  • From: Joshua D. Drake
• Re: trouble with a join on OS X
  • From: Geoffrey
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Joshua D. Drake
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Luke Lonergan
• Re: trouble with a join on OS X
  • From: Joshua D. Drake
• Re: trouble with a join on OS X
  • From: Luke Lonergan
• Re: trouble with a join on OS X
  • From: Tom Lane
• OT: Mac OS X disk buffer cache
  • From: Kevin Murphy
• Re: drive configuration for a new server
  • From: Ben
• Re: drive configuration for a new server
  • From: Jeff Frost
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Tom Lane
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Tom Lane
• Re: trouble with a join on OS X
  • From: Steinar H. Gunderson
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Tom Lane
• Re: trouble with a join on OS X
  • From: Gábriel Ákos
• Re: trouble with a join on OS X
  • From: Richard Huxton
• Re: trouble with a join on OS X
  • From: Steinar H. Gunderson
• trouble with a join on OS X
  • From: Kirk Wythers
• Re: Subselect query enhancement
  • From: Richard Huxton
• index scan through a subquery
  • From: Bill Howe
• drive configuration for a new server
  • From: Ben
• Re: Subselect query enhancement
  • From: Andrew Lazarus
• Re: int4 vs varchar to store ip addr
  • From: Michael Artz
• Re: Subselect query enhancement
  • From: Michael Artz
• Re: Subselect query enhancement
  • From: Richard Huxton
• Re: Subselect query enhancement
  • From: Michael Artz
• Re: Subselect query enhancement
  • From: Frank Wiles
• Re: Subselect query enhancement
  • From: Michael Artz
• Re: Subselect query enhancement
  • From: Ted Allen
• Re: Subselect query enhancement
  • From: Richard Huxton
• Subselect query enhancement
  • From: Michael Artz
• Using statement_timeout as a performance tool?
  • From: Mark Stosberg
• [no subject]
  • From: Unknown
• Re: Slow update
  • From: Tomas Vondra
• Re: Very slow queries
  • From: Chad Wagner
• Slow update
  • From: Abu Mushayeed
• Re: Tuning
  • From: Mischa Sandberg
• Re: Very slow queries
  • From: Sidar López Cruz
• Re: Querying distinct values from a large table
  • From: Tom Lane
• Re: Very slow queries
  • From: Sidar López Cruz
• Re: Querying distinct values from a large table
  • From: Ron
• Re: Very slow queries
  • From: Ted Allen
• Re: Very slow queries
  • From: Sidar López Cruz
• Re: Querying distinct values from a large table
  • From: Gregory Stark
• Re: Querying distinct values from a large table
  • From: Luke Lonergan
• Re: Querying distinct values from a large table
  • From: Tom Lane
• Re: Querying distinct values from a large table
  • From: Luke Lonergan
• Re: Querying distinct values from a large table
  • From: Alvaro Herrera
• Re: Querying distinct values from a large table
  • From: Josh Berkus
• Re: Very slow queries
  • From: Chad Wagner
• Re: Very slow queries
  • From: Ted Allen
• Re: Very slow queries
  • From: Sidar López Cruz
• Very slow queries
  • From: Sidar López Cruz
• Re: Querying distinct values from a large table
  • From: Steinar H. Gunderson
• Re: Querying distinct values from a large table
  • From: Luke Lonergan
• Re: Querying distinct values from a large table
  • From: Alvaro Herrera
• Re: Querying distinct values from a large table
  • From: Bruno Wolff III
• Re: Querying distinct values from a large table
  • From: Gregory Stark
• Re: Querying distinct values from a large table
  • From: Luke Lonergan
• Re: Querying distinct values from a large table
  • From: Chad Wagner
• Re: Querying distinct values from a large table
  • From: Luke Lonergan
• Re: Bad Row Count Estimate on View with 8.2
  • From: Dave Dutcher
• Re: Querying distinct values from a large table
  • From: Brian Herlihy
• Re: Querying distinct values from a large table
  • From: Chad Wagner
• Re: Querying distinct values from a large table
  • From: Richard Huxton
• Re: Querying distinct values from a large table
  • From: Simon Riggs
• Re: Querying distinct values from a large table
  • From: imad
• Re: int4 vs varchar to store ip addr
  • From: Pomarede Nicolas
• Re: Partitioning
  • From: Rigmor Ukuhe
• Re: Tuning
  • From: John Parnefjord
• Re: Querying distinct values from a large table
  • From: Richard Huxton
• Re: Querying distinct values from a large table
  • From: Igor Lobanov
• Re: Querying distinct values from a large table
  • From: Igor Lobanov
• Re: Querying distinct values from a large table
  • From: Richard Huxton
• Querying distinct values from a large table
  • From: Igor Lobanov
• Re: Partitioning
  • From: Tomas Vondra
• Partitioning
  • From: Abu Mushayeed
• Thanks All!
  • From: Saranya Sivakumar
• Re: [OT] Very strange postgresql behaviour
  • From: Carlos Moreno
• Re: int4 vs varchar to store ip addr
  • From: Cosimo Streppone
• Re: int4 vs varchar to store ip addr
  • From: Florian Weimer
• int4 vs varchar to store ip addr
  • From: Pomarede Nicolas
• Re: Tuning
  • From: Ron
• Re: [OT] Very strange postgresql behaviour
  • From: Arnau
• Re: work-mem how do I identify the proper size
  • From: Bill Moran
• Re: [OT] Very strange postgresql behaviour
  • From: Heikki Linnakangas
• Re: [OT] Very strange postgresql behaviour
  • From: Bill Moran
• [OT] Very strange postgresql behaviour
  • From: Arnau
• work-mem how do I identify the proper size
  • From: Campbell, Lance
• Re: Tuning
  • From: Tom Lane
• Re: Tuning
  • From: Josh Berkus
• Re: work_mem
  • From: Bill Moran
• Re: work-mem
  • From: imad
• work-mem
  • From: Campbell, Lance
• Re: Bad Row Count Estimate on View with 8.2
  • From: Tom Lane
• Re: Bad Row Count Estimate on View with 8.2
  • From: Dave Dutcher
• Re: IN operator causes sequential scan (vs. multiple OR expressions)
  • From: Ryan Holmes
• Re: IN operator causes sequential scan (vs. multiple OR expressions)
  • From: Tom Lane
• Re: IN operator causes sequential scan (vs. multiple OR expressions)
  • From: Ryan Holmes
• Re: IN operator causes sequential scan (vs. multiple OR expressions)
  • From: Tom Lane
• IN operator causes sequential scan (vs. multiple OR expressions)
  • From: Ryan Holmes
• Re: Seqscan/Indexscan still a known issue?
  • From: Carlos Moreno
• Re: Seqscan/Indexscan still a known issue?
  • From: Tom Lane
• Re: Seqscan/Indexscan still a known issue?
  • From: Carlos Moreno
• Re: Seqscan/Indexscan still a known issue?
  • From: Scott Marlowe
• Re: Seqscan/Indexscan still a known issue?
  • From: Russell Smith
• Re: Seqscan/Indexscan still a known issue?
  • From: Tomas Vondra
• Re: Seqscan/Indexscan still a known issue?
  • From: Guido Neitzer
• Re: Seqscan/Indexscan still a known issue?
  • From: Russell Smith
• Re: Seqscan/Indexscan still a known issue?
  • From: Dennis Bjorklund
• Seqscan/Indexscan still a known issue?
  • From: Carlos Moreno
• Re: [HACKERS] how to plan for vacuum?
  • From: Jim Nasby
• Re: Tuning
  • From: Anton Rommerskirchen
• Re: Tuning
  • From: Dave Cramer
• Tuning
  • From: John Parnefjord
• Re: [HACKERS] how to plan for vacuum?
  • From: Ray Stell
• Re: [HACKERS] how to plan for vacuum?
  • From: Joshua D. Drake
• Re: how to plan for vacuum?
  • From: Jim C. Nasby
• Re: how to plan for vacuum?
  • From: Ray Stell
• Re: how to plan for vacuum?
  • From: Galy Lee
• Re: [HACKERS] how to plan for vacuum?
  • From: Jim C. Nasby
• Re: how to plan for vacuum?
  • From: Alvaro Herrera
• Re: how to plan for vacuum?
  • From: Jim C. Nasby
• Re: slow result
  • From: Shoaib Mir
• Re: Auto Vacuum Problem
  • From: Heiko W.Rupp
• Re: Auto Vacuum Problem
  • From: Richard Huxton
• Re: Postgres processes have a burst of CPU usage
  • From: Richard Huxton
• Auto Vacuum Problem
  • From: Gauri Kanekar
• Re: how to plan for vacuum?
  • From: Galy Lee
• Re: Bad Row Count Estimate on View with 8.2
  • From: Tom Lane
• how to plan for vacuum?
  • From: Galy Lee
• Re: extract(field from timestamp) vs date dimension
  • From: Mark Kirkwood
• Re: slow result
  • From: Mark Kirkwood
• Bad Row Count Estimate on View with 8.2
  • From: Dave Dutcher
• Re: slow result
  • From: Bruno Wolff III
• Re: extract(field from timestamp) vs date dimension
  • From: Merlin Moncure
• Postgres processes have a burst of CPU usage
  • From: Subramaniam Aiylam
• Re: slow result
  • From: Ron
• Re: slow result
  • From: Bill Moran
• Re: extract(field from timestamp) vs date dimension
  • From: Tobias Brox
• Re: extract(field from timestamp) vs date dimension
  • From: Chad Wagner
• extract(field from timestamp) vs date dimension
  • From: Tobias Brox
• Re: slow result
  • From: A. Kretschmer
• slow result
  • From: Laurent Manchon
• Re: slow result
  • From: Steinar H. Gunderson
• Re: slow result
  • From: Steinar H. Gunderson
• Re: slow result
  • From: A. Kretschmer
• Re: slow result
  • From: Heiko W.Rupp
• slow result
  • From: Laurent Manchon
• Re: Table Inheritence and Partioning
  • From: Simon Riggs
• Re: [pgsql-advocacy] Postgres and really huge tables
  • From: Josh Berkus
• Re: DB benchmark and pg config file help
  • From: Kevin Hunter
• Re: Configuration Advice
  • From: Merlin Moncure
• Re: DB benchmark and pg config file help
  • From: Bruno Wolff III
• Re: Postgres and really huge tables
  • From: Merlin Moncure
• Re: DB benchmark and pg config file help
  • From: Kevin Hunter
• Re: DB benchmark and pg config file help
  • From: Merlin Moncure
• Re: [pgsql-advocacy] Postgres and really huge tables
  • From: Oleg Bartunov
• Re: Configuration Advice
  • From: Arjen van der Meijden
• Re: Postgres and really huge tables
  • From: Gavin Sherry
• Re: [pgsql-advocacy] Postgres and really huge tables
  • From: Luke Lonergan
• Re: Configuration Advice
  • From: Tom Lane
• Re: Autoanalyze settings with zero scale factor
  • From: Jeremy Haile
• Re: Postgres and really huge tables
  • From: Tom Lane
• Re: [pgsql-advocacy] Postgres and really huge tables
  • From: Chris Mair
• Re: Autoanalyze settings with zero scale factor
  • From: Tom Lane
• Re: Configuration Advice
  • From: Arjen van der Meijden
• Re: Postgres and really huge tables
  • From: Scott Marlowe
• Re: Autoanalyze settings with zero scale factor
  • From: Matthew T. O'Connor
• Re: [pgsql-advocacy] Postgres and really huge tables
  • From: Joshua D. Drake
• Postgres and really huge tables
  • From: Brian Hurt
• Re: Autoanalyze settings with zero scale factor
  • From: Jeremy Haile
• Re: Autoanalyze settings with zero scale factor
  • From: Matthew T. O'Connor
• Autoanalyze settings with zero scale factor
  • From: Jeremy Haile
• Re: Configuration Advice
  • From: Jeremy Haile
• Re: Configuration Advice
  • From: Arjen van der Meijden
• Re: Configuration Advice
  • From: Scott Marlowe
• Re: Configuration Advice
  • From: Scott Marlowe
• Re: Vacuum v/s Autovacuum
  • From: Shoaib Mir
• Re: Vacuum v/s Autovacuum
  • From: Bill Moran
• Re: Vacuum v/s Autovacuum
  • From: Gauri Kanekar
• Re: Vacuum v/s Autovacuum
  • From: Michael Glaesemann
• Vacuum v/s Autovacuum
  • From: Gauri Kanekar
• Re: Configuration Advice
  • From: Arjen van der Meijden
• Re: Monitoring Transaction Log size
  • From: Shoaib Mir
• Re: Monitoring Transaction Log size
  • From: Simon Riggs
• Re: Version Change
  • From: Michael Glaesemann
• Re: Version Change
  • From: Michael Glaesemann
• Re: Version Change
  • From: Michael Glaesemann
• Version Change
  • From: Gauri Kanekar
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Chris Browne
• Re: Configuration Advice
  • From: Chad Wagner
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Dave Cramer
• Re: Configuration Advice
  • From: Adam Rich
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Scott Marlowe
• Re: Monitoring Transaction Log size
  • From: Tom Lane
• DB benchmark and pg config file help
  • From: Kevin Hunter
• Re: Configuration Advice
  • From: Bruno Wolff III
• Re: Configuration Advice
  • From: Joshua D. Drake
• Re: Configuration Advice
  • From: Benjamin Minshall
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Heikki Linnakangas
• Re: Configuration Advice
  • From: Chad Wagner
• Re: Configuration Advice
  • From: Tomas Vondra
• Re: Configuration Advice
  • From: Bricklen Anderson
• Re: Configuration Advice
  • From: Adam Rich
• Configuration Advice
  • From: Steve
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Tomas Vondra
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Tomas Vondra
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Scott Marlowe
• Re: Monitoring Transaction Log size
  • From: Stefan Kaltenbrunner
• Re: Monitoring Transaction Log size
  • From: Shoaib Mir
• Re: Monitoring Transaction Log size
  • From: Joshua D. Drake
• Monitoring Transaction Log size
  • From: Ziegelwanger, Silvio
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Chad Wagner
• Re: [HACKERS] unusual performance for vac following 8.2
  • From: Kim
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Scott Marlowe
• Raid 10 or Raid 5 on Dell PowerEdge
  • From: Dave Dutcher
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Dave Cramer
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Shoaib Mir
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: Table Inheritence and Partioning
  • From: Albert Cervera Areny
• Table Inheritence and Partioning
  • From: ramachandra.bhaskaram
• Re: Table Size
  • From: Guillaume Lelarge
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Scott Marlowe
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Chad Wagner
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Chad Wagner
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Tom Lane
• PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: Table Size
  • From: Richard Huxton
• Re: Caching in PostgreSQL
  • From: Chris Browne
• Table Size
  • From: Gauri Kanekar
• Re: Caching in PostgreSQL
  • From: David Levy
• Re: Caching in PostgreSQL
  • From: Heikki Linnakangas
• Re: Caching in PostgreSQL
  • From: ramachandra.bhaskaram
• Re: Caching in PostgreSQL
  • From: Heikki Linnakangas
• Caching in PostgreSQL
  • From: ramachandra.bhaskaram
• FiberChannel cards for FreeBSD on AMD64
  • From: Andrew Hammond
• Re: max() versus order/limit (WAS: High update
  • From: Joshua D. Drake
• Re: pg_trgm performance
  • From: Steinar H. Gunderson
• Re: max() versus order/limit (WAS: High update
  • From: Alvaro Herrera
• Re: max() versus order/limit (WAS: High update activity, PostgreSQL vs BigDBMS)
  • From: Alvaro Herrera
• pg_trgm performance
  • From: Florian Weimer
• Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)
  • From: Rolf Østvik (HA/EXA)
• Re: max() versus order/limit (WAS: High update
  • From: Luke Lonergan
• Re: max() versus order/limit (WAS: High update activity, PostgreSQL vs BigDBMS)
  • From: Adam Rich
• Re: Large table performance
  • From: Luke Lonergan
• Re: Large table performance
  • From: Luke Lonergan
• Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)
  • From: Dave Cramer
• Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)
  • From: Dave Dutcher
• Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)
  • From: Rolf Østvik (HA/EXA)
• Re:
  • From: Dave Cramer
• Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)
  • From: Rolf Østvik (HA/EXA)
• [no subject]
  • From: Rolf Østvik (HA/EXA)
• Re: Large table performance
  • From: Shoaib Mir
• Re: Performance of Parser?
  • From: Dave Cramer
• Re: Large table performance
  • From: Dave Dutcher
• Re: Performance of Parser?
  • From: Tom Lane
• Performance of Parser?
  • From: Jignesh Shah
• Re: Large table performance
  • From: Daniel Cristian Cruz
• Physical separation of tables and indexes - where pg_xlog should go?
  • From: Ireneusz Pluta
• Re: Large table performance
  • From: Steinar H. Gunderson
• Re: Large table performance
  • From: Dave Cramer
• Large table performance
  • From: Mark Dobbrow
• Re: [HACKERS] table partioning performance
  • From: Simon Riggs
• RES: Improving SQL performance
  • From: Carlos H. Reimer
• Partitioning
  • From: Gauri Kanekar
• Re: Planner statistics, correlations
  • From: Heikki Linnakangas
• Re: Planner statistics, correlations
  • From: Tobias Brox
• Re: Planner statistics, correlations
  • From: Heikki Linnakangas
• Re: Planner statistics, correlations
  • From: Tobias Brox
• Re: Planner statistics, correlations
  • From: Richard Huxton
• Re: [HACKERS] unusual performance for vac following 8.2upgrade
  • From: Richard Huxton
• Re: Planner statistics, correlations
  • From: Tobias Brox
• Re: Planner statistics, correlations
  • From: Peter Childs
• Planner statistics, correlations
  • From: Tobias Brox
• Re: [HACKERS] unusual performance for vac following 8.2upgrade
  • From: Tom Lane
• Re: [HACKERS] unusual performance for vac following 8.2upgrade
  • From: Alvaro Herrera
• Re: RES: Improving SQL performance
  • From: Cesar Suga
• Re: [HACKERS] unusual performance for vac following 8.2upgrade
  • From: Simon Riggs
• Re: unusual performance for vac following 8.2 upgrade
  • From: Kim
• Re: [HACKERS] unusual performance for vac following 8.2 upgrade
  • From: Tom Lane
• Re: unusual performance for vac following 8.2 upgrade
  • From: Tom Lane
• Re: unusual performance for vac following 8.2 upgrade
  • From: Kim
• Re: [HACKERS] unusual performance for vac following 8.2 upgrade
  • From: Jim C. Nasby
• RES: Improving SQL performance
  • From: Carlos H. Reimer
• Re: [HACKERS] unusual performance for vac following 8.2 upgrade
  • From: Tom Lane
• Re: [HACKERS] table partioning performance
  • From: Jim C. Nasby
• Re: unusual performance for vac following 8.2 upgrade
  • From: Simon Riggs
• Re: [HACKERS] unusual performance for vac following 8.2 upgrade
  • From: Alvaro Herrera
• Re: unusual performance for vac following 8.2 upgrade
  • From: Tom Lane