Postgres Performance Date Index

• Thread Index

• Re: Performance with 2 AMD/Opteron 2.6Ghz and 8gig
  • From: Mikael Carneholm
• Re: Performance with 2 AMD/Opteron 2.6Ghz and 8gig
  • From: Luke Lonergan
• Re: Performance with 2 AMD/Opteron 2.6Ghz and 8gig
  • From: Luke Lonergan
• Re: Performance with 2 AMD/Opteron 2.6Ghz and 8gig
  • From: Mikael Carneholm
• Re: Performance with 2 AMD/Opteron 2.6Ghz and 8gig
  • From: Luke Lonergan
• Performance with 2 AMD/Opteron 2.6Ghz and 8gig DDR PC3200
  • From: Kjell Tore Fossbakk
• Re: Disk writes
  • From: Florian Weimer
• Re: Savepoint performance
  • From: Denis Lussier
• Re: Savepoint performance
  • From: Tom Lane
• Disk writes
  • From: carlosreimer
• Re: Savepoint performance
  • From: Denis Lussier
• Re: Savepoint performance
  • From: Jaime Casanova
• Re: Query plan issue when upgrading to postgres 8.14 (from
  • From: Tom Lane
• Strange behaviour
  • From: Richard Rowell
• Re: performance issue with a specific query
  • From: Tom Lane
• Re: Savepoint performance
  • From: Alvaro Herrera
• Re: Query plan issue when upgrading to postgres 8.14 (from
  • From: Ioana Danes
• Savepoint performance
  • From: Mark Lewis
• Re: performance issue with a specific query
  • From: Alvaro Herrera
• Query 200x slower on server [PART 2]
  • From: NbForYou
• How to increase performance?
  • From: Hristo Markov
• Re: performance issue with a specific query
  • From: Joshua D. Drake
• Re: performance issue with a specific query
  • From: Merlin Moncure
• Re: performance issue with a specific query
  • From: Scott Marlowe
• performance issue with a specific query
  • From: Eliott
• Re: Is it possible to speed this query up?
  • From: Tom Lane
• Is it possible to speed this query up?
  • From: Arnau
• Re: loading increase into huge table with 50.000.000 records
  • From: Merlin Moncure
• Re: loading increase into huge table with 50.000.000 records
  • From: Markus Schaber
• Re: loading increase into huge table with 50.000.000 records
  • From: Sven Geisler
• loading increase into huge table with 50.000.000 records
  • From: nuggets72
• Re: Partitioned tables in queries
  • From: Andrew Hammond
• Re: BUG #2543: Performance delay acrros the same day
  • From: Markus Schaber
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Robert Lor
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Tom Lane
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Robert Lor
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Tom Lane
• Re: postgres benchmarks
  • From: Denis Lussier
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Tom Lane
• Re: Forcing using index instead of sequential scan?
  • From: Craig A. James
• Re: Forcing using index instead of sequential scan?
  • From: Michael Stone
• Re: Forcing using index instead of sequential scan?
  • From: Mark Kirkwood
• Re: Forcing using index instead of sequential scan?
  • From: Mark Kirkwood
• Re: Forcing using index instead of sequential scan?
  • From: Gregory Stark
• Re: Forcing using index instead of sequential scan?
  • From: Craig A. James
• Re: Bad Planner Statistics for Uneven distribution.
  • From: Tom Lane
• Re: Forcing using index instead of sequential scan?
  • From: Tom Lane
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Robert Lor
• Re: Bad Planner Statistics for Uneven distribution.
  • From: Guillaume Smet
• Re: Bad Planner Statistics for Uneven distribution.
  • From: Tom Lane
• Re: Partitioned tables in queries
  • From: Kevin Keith
• Re: Partitioned tables in queries
  • From: Steve Atkins
• Partitioned tables in queries
  • From: Kevin Keith
• Bad Planner Statistics for Uneven distribution.
  • From: Kevin McArthur
• Re: BUG #2543: Performance delay acrros the same day
  • From: Bruno Wolff III
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Robert Lor
• Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Sven Geisler
• Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Jim C. Nasby
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Tom Lane
• postgres benchmarks
  • From: Petronenko D.S.
• Re: Forcing using index instead of sequential scan?
  • From: Peter Eisentraut
• Re: Forcing using index instead of sequential scan?
  • From: robin.c.smith
• Re: Forcing using index instead of sequential scan?
  • From: robin.c.smith
• Forcing using index instead of sequential scan?
  • From: robin.c.smith
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Robert Lor
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Tom Lane
• Re: Performance penalty for remote access of postgresql
  • From: David Boreham
• Re: Performance penalty for remote access of postgresql (8.1.3)? any experiance?
  • From: Guoping Zhang
• Re: Performance penalty for remote access of postgresql
  • From: Joe Conway
• Re: Performance penalty for remote access of postgresql
  • From: Bill Moran
• Re: Performance penalty for remote access of postgresql (8.1.3)? any experiance?
  • From: Stephen Frost
• Re: Performance penalty for remote access of postgresql (8.1.3)? any experiance?
  • From: Florian Weimer
• Re: Performance penalty for remote access of postgresql (8.1.3)? any experiance?
  • From: Stephen Frost
• Re: Performance penalty for remote access of postgresql (8.1.3)? any experiance?
  • From: Florian Weimer
• Re: Performance penalty for remote access of postgresql (8.1.3)? any experiance?
  • From: Guoping Zhang
• Re: Performance penalty for remote access of postgresql (8.1.3)? any experiance?
  • From: Florian Weimer
• Performance penalty for remote access of postgresql (8.1.3)? any experiance?
  • From: Guoping Zhang
• Re: Query plan issue when upgrading to postgres 8.14 (from
  • From: Ioana Danes
• Re: RAID stripe size question
  • From: Milen Kulev
• Re: RAID stripe size question
  • From: Scott Marlowe
• Re: RAID stripe size question
  • From: Ron Peacetree
• Re: RAID stripe size question
  • From: Scott Marlowe
• Re: RAID stripe size question
  • From: Alex Turner
• Re: RAID stripe size question
  • From: Luke Lonergan
• Re: Temporary table retains old contents on update eventually causing slow temp file usage.
  • From: Rusty Conover
• Re: RAID stripe size question
  • From: Mikael Carneholm
• Re: RAID stripe size question
  • From: Ron Peacetree
• Re: Temporary table retains old contents on update eventually
  • From: Gavin Sherry
• Temporary table retains old contents on update eventually causing slow temp file usage.
  • From: Rusty Conover
• Re: Temporary table retains old contents on update eventually causing slow temp file usage.
  • From: Rusty Conover
• Re: Big differences in plans between 8.0 and 8.1
  • From: Gabriele Turchi
• Re: Problem with bitmap-index-scan plan
  • From: Kapadaidakis Yannis
• Re: RAID stripe size question
  • From: Alex Turner
• Re: RAID stripe size question
  • From: Ron Peacetree
• Re: RAID stripe size question
  • From: Mark Kirkwood
• Re: RAID stripe size question
  • From: Mikael Carneholm
• Re: Big differences in plans between 8.0 and 8.1
  • From: Chris Hoover
• Re: RAID stripe size question
  • From: Alex Turner
• Re: RAID stripe size question
  • From: Steinar H. Gunderson
• Re: RAID stripe size question
  • From: Ron Peacetree
• Re: RAID stripe size question
  • From: Mikael Carneholm
• Re: RAID stripe size question
  • From: Markus Schaber
• Re: RAID stripe size question
  • From: Mikael Carneholm
• Re: RAID stripe size question
  • From: Markus Schaber
• Re: RAID stripe size question
  • From: Mikael Carneholm
• Re: RAID stripe size question
  • From: Alex Turner
• Re: RAID stripe size question
  • From: Michael Stone
• Re: RAID stripe size question
  • From: Steinar H. Gunderson
• RAID stripe size question
  • From: Mikael Carneholm
• Re: Big differences in plans between 8.0 and 8.1
  • From: Joe Conway
• Re: increment Rows in an SQL Result Set postgresql
  • From: Peter Eisentraut
• Re: Big differences in plans between 8.0 and 8.1
  • From: Gabriele Turchi
• Re: Big differences in plans between 8.0 and 8.1
  • From: Joe Conway
• Re: Big differences in plans between 8.0 and 8.1
  • From: Gabriele Turchi
• Re: Big differences in plans between 8.0 and 8.1
  • From: Michael Fuhr
• Re: increment Rows in an SQL Result Set postgresql
  • From: Hassan
• Re: increment Rows in an SQL Result Set postgresql
  • From: Craig A. James
• increment Rows in an SQL Result Set postgresql
  • From: Hassan Adekoya
• Big differences in plans between 8.0 and 8.1
  • From: Gabriele Turchi
• Re: Self-join query and index usage
  • From: Tom Lane
• Self-join query and index usage
  • From: worky . workerson
• Re: Kill a session
  • From: Tom Lane
• Re: Kill a session
  • From: Craig A. James
• Re: Kill a session
  • From: Markus Schaber
• Re: size of pg_dump files containing bytea values
  • From: Florian Weimer
• Re: Kill a session
  • From: Tom Lane
• Re: Kill a session
  • From: Craig A. James
• Re: Kill a session
  • From: Craig A. James
• Re: Kill a session
  • From: Mark Kirkwood
• Re: Problem with bitmap-index-scan plan
  • From: Tom Lane
• Re: hyper slow after upgrade to 8.1.4
  • From: Medora Schauer
• Re: size of pg_dump files containing bytea values
  • From: Tom Lane
• Re: hyper slow after upgrade to 8.1.4
  • From: Tom Lane
• Re: size of pg_dump files containing bytea values
  • From: Greg Stark
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Tom Lane
• Re: hyper slow after upgrade to 8.1.4
  • From: Michael Fuhr
• Re: hyper slow after upgrade to 8.1.4
  • From: Medora Schauer
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Tatsuo Ishii
• Re: Commit slower on faster PC
  • From: Koth, Christian (DWBI)
• Re: [Fwd: Delivery Status Notification (Failure)]
  • From: Tom Lane
• Re: size of pg_dump files containing bytea values
  • From: Tom Lane
• Re: hyper slow after upgrade to 8.1.4
  • From: Bruno Wolff III
• Re: [Fwd: Delivery Status Notification (Failure)]
  • From: Richard Broersma Jr
• Re: hyper slow after upgrade to 8.1.4
  • From: Joshua D. Drake
• Re: [Fwd: Delivery Status Notification (Failure)]
  • From: Craig A. James
• hyper slow after upgrade to 8.1.4
  • From: Medora Schauer
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Jeff Frost
• Re: [Fwd: Delivery Status Notification (Failure)]
  • From: Richard Broersma Jr
• Re: [Fwd: Delivery Status Notification (Failure)]
  • From: Michael Glaesemann
• Re: Commit slower on faster PC
  • From: Bruno Wolff III
• size of pg_dump files containing bytea values
  • From: Steve McWilliams
• Re: Commit slower on faster PC
  • From: Joshua D. Drake
• [Fwd: Delivery Status Notification (Failure)]
  • From: Craig A. James
• Re: Kill a session
  • From: Stefan Kaltenbrunner
• Re: Commit slower on faster PC
  • From: D'Arcy J.M. Cain
• Re: Commit slower on faster PC
  • From: Mark Lewis
• Re: Kill a session
  • From: Magnus Hagander
• Re: Kill a session
  • From: Steinar H. Gunderson
• Re: Kill a session
  • From: Craig A. James
• Commit slower on faster PC
  • From: Koth, Christian (DWBI)
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Jeff Frost
• Re: Performance Problem between Ora 10g and Psql
  • From: Joshua D. Drake
• Re: Performance Problem between Ora 10g and Psql
  • From: Guillaume Smet
• Performance Problem between Ora 10g and Psql
  • From: Thomas Radnetter
• Out of Memory Problem.
  • From: nicky
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Neil Hepworth
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Jeff Frost
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Jeff Frost
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Neil Hepworth
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Bruno Wolff III
• Unsubscribe
  • From: Jghaffou
• Re: Kill a session
  • From: Magnus Hagander
• Re: Kill a session
  • From: Tino Wildenhain
• Kill a session
  • From: Craig A. James
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Scott Marlowe
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Jeff Frost
• Re: suggested RAID controller for FreeBSD 6.1 + PostgreSQL 8.1
  • From: Vivek Khera
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Neil Hepworth
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Neil Hepworth
• Re: High CPU Usage - PostgreSQL 7.3
  • From: Jeff Frost
• High CPU Usage - PostgreSQL 7.3
  • From: Neil Hepworth
• Re: Opteron/FreeBSD/PostgreSQL performance poor
  • From: Merlin Moncure
• Re: VACUUM vs. REINDEX
  • From: Stefan Kaltenbrunner
• Re: VACUUM vs. REINDEX
  • From: Steinar H. Gunderson
• Re: VACUUM vs. REINDEX
  • From: Joshua D. Drake
• Re: VACUUM vs. REINDEX
  • From: Chris Hoover
• Re: VACUUM vs. REINDEX
  • From: Joshua D. Drake
• Re: VACUUM vs. REINDEX
  • From: William Scott Jordan
• Re: VACUUM vs. REINDEX
  • From: Jeff Frost
• Re: VACUUM vs. REINDEX
  • From: William Scott Jordan
• Re: VACUUM vs. REINDEX
  • From: Jeff Frost
• Re: VACUUM vs. REINDEX
  • From: Richard Broersma Jr
• VACUUM vs. REINDEX
  • From: William Scott Jordan
• Re: Opteron/FreeBSD/PostgreSQL performance poor
  • From: Jeff Frost
• Delete is very slow; PG not using existing index to check foreign keys
  • From: K-Bob body
• Re: Opteron/FreeBSD/PostgreSQL performance poor
  • From: andy rost
• Re: Opteron/FreeBSD/PostgreSQL performance poor
  • From: andy rost
• Re: how to tune this query.
  • From: Merlin Moncure
• Re: Update INSERT RULE while running for Partitioning
  • From: Dave Chapeskie
• Re: suggested RAID controller for FreeBSD 6.1 +
  • From: Ron Peacetree
• Re: Calling a SP from Curosor loop
  • From: Merlin Moncure
• longest prefix match querries
  • From: Hripchenko Sergey
• Re: Update INSERT RULE while running for Partitioning
  • From: Markus Schaber
• Re: need vacuum after insert/truncate/insert?
  • From: Markus Schaber
• Re: getting better performance
  • From: Markus Schaber
• Update INSERT RULE while running for Partitioning
  • From: Gene
• Query plan issue when upgrading to postgres 8.14 (from postgres 8.12 or 7.4)
  • From: Ioana Danes
• Re: suggested RAID controller for FreeBSD 6.1 +PostgreSQL
  • From: Michael Loftis
• need vacuum after insert/truncate/insert?
  • From: Craig A. James
• Re: Query plan issue when upgrading to postgres 8.14 (from
  • From: Chris
• Query plan issue when upgrading to postgres 8.14 (from postgres 8.12 or 7.4)
  • From: Ioana Danes
• Re: suggested RAID controller for FreeBSD 6.1 + PostgreSQL
  • From: Mark Kirkwood
• Re: suggested RAID controller for FreeBSD 6.1 +PostgreSQL 8.1
  • From: Paul Khavkine
• Re: suggested RAID controller for FreeBSD 6.1 +
  • From: Scott Marlowe
• Re: suggested RAID controller for FreeBSD 6.1 + PostgreSQL 8.1
  • From: Kenji Morishige
• Re: victory!
  • From: A.M.
• victory!
  • From: Merlin Moncure
• unsubscribe
  • From: Lorenzo Pasquinelli
• Re: getting better performance
  • From: Scott Marlowe
• Re: getting better performance
  • From: Merlin Moncure
• Re: getting better performance
  • From: Eugeny N Dzhurinsky
• Re: Opteron/FreeBSD/PostgreSQL performance poor
  • From: Merlin Moncure
• Re: getting better performance
  • From: Scott Marlowe
• unsubscribe
  • From: Vipul . Gupta
• unsubscribe
  • From: Monique . Lu
• Re: getting better performance
  • From: Ivan Zolotukhin
• Re: unsubscribe
  • From: Chethana, Rao (IE10)
• Re: getting better performance
  • From: A. Kretschmer
• getting better performance
  • From: Eugeny N Dzhurinsky
• Re: suggested RAID controller for FreeBSD 6.1 + PostgreSQL
  • From: Mark Kirkwood
• Re: managing database with thousands of tables
  • From: Chris
• suggested RAID controller for FreeBSD 6.1 + PostgreSQL 8.1
  • From: Kenji Morishige
• Re: Opteron/FreeBSD/PostgreSQL performance poor
  • From: Mark Kirkwood
• Re: Is postgresql ca do the job for software deployed in
  • From: Markus Schaber
• Re: Opteron/FreeBSD/PostgreSQL performance poor
  • From: andy rost
• Re: Opteron/FreeBSD/PostgreSQL performance poor
  • From: Vivek Khera
• Re: managing database with thousands of tables
  • From: Eugeny N Dzhurinsky
• Re: Opteron/FreeBSD/PostgreSQL performance poor
  • From: Stephen Frost
• Opteron/FreeBSD/PostgreSQL performance poor
  • From: andy rost
• Re: managing database with thousands of tables
  • From: Tom Lane
• managing database with thousands of tables
  • From: Eugeny N Dzhurinsky
• Re: Is postgresql ca do the job for software deployed in
  • From: Gregory S. Williamson
• Re: Is postgresql ca do the job for software deployed in
  • From: Markus Schaber
• Problem with bitmap-index-scan plan
  • From: jkapad
• Re: optimizing LIKE '%2345' queries
  • From: Chris
• Re: optimizing LIKE '%2345' queries
  • From: Gene
• Re: how to tune this query.
  • From: Nolan Cafferky
• how to tune this query.
  • From: Luckys
• Re: Is postgresql ca do the job for software deployed in ASP
  • From: David Gagnon
• Re: Is postgresql ca do the job for software deployed in ASP ou SaaS mode?
  • From: Mikael Carneholm
• Re: Is postgresql ca do the job for software deployed in ASP
  • From: David Gagnon
• Re: optimizing LIKE '%2345' queries
  • From: Tarhon-Onu Victor
• Re: Is postgresql ca do the job for software deployed in ASP ou SaaS mode?
  • From: Mikael Carneholm
• Re: Is postgresql ca do the job for software deployed in ASP ou SaaS mode?
  • From: Guoping Zhang
• Re: [BUGS] query very slow when enable_seqscan=on
  • From: Simon Riggs
• Re: Is postgresql ca do the job for software deployed in
  • From: Craig A. James
• Re: Is postgresql ca do the job for software deployed in ASP ou SaaS mode?
  • From: Chris Hoover
• Re: Is postgresql ca do the job for software deployed in ASP ou SaaS mode?
  • From: Richard Broersma Jr
• Is postgresql ca do the job for software deployed in ASP ou SaaS mode?
  • From: David Gagnon
• Re: optimizing LIKE '%2345' queries
  • From: Mario Weilguni
• optimizing LIKE '%2345' queries
  • From: Gene
• Re: FWD: Update touches unrelated indexes?
  • From: Jaime Casanova
• Re: [pgadmin-support] 100% CPU
  • From: Mark Kirkwood
• Re: Index Being Ignored?
  • From: Alvaro Herrera
• Re: [pgadmin-support] 100% CPU
  • From: Jim C. Nasby
• Re: FWD: Update touches unrelated indexes?
  • From: Alvaro Herrera
• Re: Index Being Ignored?
  • From: Joe Lester
• Re: FWD: Update touches unrelated indexes?
  • From: Jozsef Szalay
• Re: Index Being Ignored?
  • From: Tom Lane
• Re: newly created database makes queries run 300% faster
  • From: Brad Nicholson
• Re: Index Being Ignored?
  • From: Markus Schaber
• newly created database makes queries run 300% faster
  • From: Ksenia Marasanova
• Index Being Ignored?
  • From: Joe Lester
• Re: FWD: Update touches unrelated indexes?
  • From: Tom Lane
• FWD: Update touches unrelated indexes?
  • From: Josh Berkus
• Re: Sort order in sub-select
  • From: Tom Lane
• Re: explain analyze reports 20x more time than actual
  • From: Tom Lane
• Sort order in sub-select
  • From: Craig A. James
• explain analyze reports 20x more time than actual
  • From: Craig A. James
• Calling a SP from Curosor loop
  • From: satishchandra999
• Re: Some performance numbers, with thoughts
  • From: Ron Mayer
• Re: Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)
  • From: Jim C. Nasby
• Re: Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)
  • From: Tom Lane
• Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)
  • From: Andrew Sagulin
• Re: Large index scan perfomance and indexCorrelation (PG
  • From: Simon Riggs
• Re: why group expressions cause query to run forever
  • From: Andrus
• unregister
  • From: Leandro Guimarães dos Santos
• unregister
  • From: Gourish Singbal
• Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)
  • From: Andrew Sagulin
• Re: Some performance numbers, with thoughts
  • From: Simon Riggs
• unsubscribe
  • From: Diego Gaviola
• Re: Some performance numbers, with thoughts
  • From: Michael Stone
• Re: Some performance numbers, with thoughts
  • From: Simon Riggs
• Re: Occupation bloc in pages of table
  • From: luchot
• Re: Occupation bloc in pages of table
  • From: luchot
• Re: why group expressions cause query to run forever
  • From: Andrus
• Re: Occupation bloc in pages of table
  • From: luchot
• Sort order in sub-select
  • From: Craig A. James
• Re: Optimizer internals
  • From: Bruno Wolff III
• RES: Temporary table
  • From: Franklin Haut
• Re: Temporary table
  • From: Larry Rosenman
• Re: Temporary table
  • From: Tom Lane
• Temporary table
  • From: Franklin Haut
• Buffers to Nest Loop Join
  • From: Daniel Xavier de Sousa
• Re: Occupation bloc in pages of table
  • From: Tom Lane
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: Markus Schaber
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: Markus Schaber
• Re: SAN performance mystery
  • From: Markus Schaber
• Re: SAN performance mystery
  • From: Markus Schaber
• Occupation bloc in pages of table
  • From: luchot
• Re: Why is my (empty) partial index query slow?
  • From: Tom Lane
• Re: Query hanging/not finishing inconsistently
  • From: Tom Lane
• Re: Tuning New Server (slow function)
  • From: Jim Nasby
• Re: why group expressions cause query to run forever
  • From: Tom Lane
• why group expressions cause query to run forever
  • From: Andrus
• Re: Performance of DOMAINs
  • From: David Wheeler
• Re: Performance of DOMAINs
  • From: David Wheeler
• Re: Performance of DOMAINs
  • From: David Wheeler
• Re: Poor performance - fixed by restart
  • From: Tom Lane
• Re: Tuning New Server (slow function)
  • From: Tom Lane
• Re: Why is my (empty) partial index query slow?
  • From: Tom Lane
• Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Craig A. James
• Re: Regarding ERROR: fmgr_info: function 2720768: cache lookup failed
  • From: Tom Lane
• Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Arjen van der Meijden
• Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: David Roussel
• Re: Speeding up query, Joining 55mil and 43mil records.
  • From: Sven Geisler
• Re: Speeding up query, Joining 55mil and 43mil records.
  • From: Magnus Hagander
• Re: Speeding up query, Joining 55mil and 43mil records.
  • From: nicky
• Re: Speeding up query, Joining 55mil and 43mil records.
  • From: Sven Geisler
• Re: Speeding up query, Joining 55mil and 43mil records.
  • From: nicky
• Regarding ERROR: fmgr_info: function 2720768: cache lookup failed
  • From: soni de
• Re: Performance of DOMAINs
  • From: Michael Glaesemann
• Re: Performance of DOMAINs
  • From: Josh Berkus
• Poor performance - fixed by restart
  • From: Peter Wilson
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: jody brownell
• Re: Tuning New Server (slow function)
  • From: Ron St-Pierre
• Re: Tuning New Server (slow function)
  • From: Jim C. Nasby
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: Jim C. Nasby
• Tuning New Server (slow function)
  • From: Ron St-Pierre
• Re: Quick question about top...
  • From: Steinar H. Gunderson
• Quick question about top...
  • From: Alex Turner
• Re: Performance of DOMAINs
  • From: Tom Lane
• Re: Big array speed issues
  • From: Merlin Moncure
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: jody brownell
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: jody brownell
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: Jim C. Nasby
• Re: Performance of DOMAINs
  • From: Jim C. Nasby
• Re: Help tuning autovacuum - seeing lots of relation bloat
  • From: Jim C. Nasby
• Re: Speeding up query, Joining 55mil and 43mil records.
  • From: Jim C. Nasby
• Re: Big array speed issues
  • From: Jim C. Nasby
• Performance of DOMAINs
  • From: David Wheeler
• Re: Speeding up query, Joining 55mil and 43mil records.
  • From: Tom Lane
• Re: Speeding up query, Joining 55mil and 43mil records.
  • From: Scott Marlowe
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: jody brownell
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: Csaba Nagy
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: jody brownell
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: Csaba Nagy
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: jody brownell
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: jody brownell
• Tuning New Server (slow function)
  • From: Ron St-Pierre
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: Csaba Nagy
• Tuning New Server (slow function)
  • From: Ron St-Pierre
• Re: Speeding up query, Joining 55mil and 43mil records.
  • From: Sven Geisler
• Re: Help tuning autovacuum - seeing lots of relationbloat
  • From: jody brownell
• Re: Speeding up query, Joining 55mil and 43mil records.
  • From: Dave Dutcher
• Speeding up query, Joining 55mil and 43mil records.
  • From: nicky
• Re: Help tuning autovacuum - seeing lots of relation
  • From: Tom Lane
• Re: Help tuning autovacuum - seeing lots of relation
  • From: Csaba Nagy
• Help tuning autovacuum - seeing lots of relation bloat
  • From: jody brownell
• Re: Some queries starting to hang
  • From: Markus Schaber
• Re: scaling up postgres
  • From: Markus Schaber
• Re: Big array speed issues
  • From: Merkel Marcel (CR/AEM4)
• Re: scaling up postgres
  • From: Markus Schaber
• ACL cleanup
  • From: Eric Lauzon
• Re: Big array speed issues
  • From: Merlin Moncure
• Re: Query hanging/not finishing inconsistently
  • From: Meetesh Karia
• Re: lowering priority automatically at connection
  • From: Markus Schaber
• Re: Curson prbolem
  • From: Tom Lane
• Curson prbolem
  • From: biuro
• Big array speed issues
  • From: Merkel Marcel (CR/AEM4)
• Re: Some performance numbers, with thoughts
  • From: Luke Lonergan
• Re: Some performance numbers, with thoughts
  • From: Tom Lane
• Some performance numbers, with thoughts
  • From: Brian Hurt
• Re: SAN performance mystery
  • From: Mark Kirkwood
• Re: SAN performance mystery
  • From: Stephen Frost
• Re: SAN performance mystery
  • From: John Vincent
• Re: SAN performance mystery
  • From: John Vincent
• Re: SAN performance mystery
  • From: John Vincent
• Re: SAN performance mystery
  • From: Stephen Frost
• Re: SAN performance mystery
  • From: Tim Allen
• Re: SAN performance mystery
  • From: Michael Stone
• Re: SAN performance mystery
  • From: Tim Allen
• Re: SAN performance mystery
  • From: Tim Allen
• Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Arjen van der Meijden
• Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Andrew Dunstan
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL community
  • From: Jim Nasby
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL community
  • From: Jim Nasby
• Re: SAN performance mystery
  • From: Jim Nasby
• Re: Optimizer internals
  • From: Jim Nasby
• Re: Precomputed constants?
  • From: Jim Nasby
• Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Josh Berkus
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL community
  • From: Robert Lor
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Tatsuo Ishii
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Tom Lane
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
  • From: Tatsuo Ishii
• Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL community
  • From: Josh Berkus
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL community
  • From: Arjen van der Meijden
• Re: Question about clustering multiple columns
  • From: Benjamin Arai
• Re: Question about clustering multiple columns
  • From: Bruno Wolff III
• Re: SAN performance mystery
  • From: Jeff Trout
• Re: Sun Donated a Sun Fire T2000 to the PostgreSQL community
  • From: Josh Berkus
• Re: Question about clustering multiple columns
  • From: Bruno Wolff III
• Sun Donated a Sun Fire T2000 to the PostgreSQL community
  • From: Robert Lor
• Re: SAN performance mystery
  • From: Merlin Moncure
• Re: Optimizer internals
  • From: Jonah H. Harris
• Re: Delete operation VERY slow...
  • From: Tom Lane
• Re: Optimizer internals
  • From: Greg Stark
• Re: Optimizer internals
  • From: Jonah H. Harris
• Re: how to partition disks
  • From: Michael Stone
• Re: SAN performance mystery
  • From: Mikael Carneholm
• Re: SAN performance mystery
  • From: Greg Stark
• Re: Optimizer internals
  • From: Greg Stark
• Re: Delete operation VERY slow...
  • From: PFC
• Re: SAN performance mystery
  • From: Tim Allen
• Re: Delete operation VERY slow...
  • From: David Leangen
• Re: SAN performance mystery
  • From: Stefan Kaltenbrunner
• Why is my (empty) partial index query slow?
  • From: Richard Frith-Macdonald
• Re: Delete operation VERY slow...
  • From: Gourish Singbal
• Re: Delete operation VERY slow...
  • From: A. Kretschmer
• Delete operation VERY slow...
  • From: David Leangen
• Re: Performance of pg_dump on PGSQL 8.0
  • From: Merlin Moncure
• Re: Optimizer internals
  • From: Mischa Sandberg
• Re: SAN performance mystery
  • From: Alex Turner
• Re: SAN performance mystery
  • From: Mark Lewis
• Re: Optimizer internals
  • From: John Vincent
• Re: SAN performance mystery
  • From: Tom Lane
• Re: Optimizer internals
  • From: Jim C. Nasby
• Re: SAN performance mystery
  • From: John Vincent
• Re: SAN performance mystery
  • From: Brian Hurt
• Re: SAN performance mystery
  • From: Scott Marlowe
• SAN performance mystery
  • From: Tim Allen
• Re: Optimizer internals
  • From: John Vincent
• Re: Optimizer internals
  • From: John Vincent
• Re: Optimizer internals
  • From: Scott Marlowe
• Re: Optimizer internals
  • From: John Vincent
• Re: Optimizer internals
  • From: Mark Lewis
• Re: Optimizer internals
  • From: John Vincent
• Re: Optimizer internals
  • From: Mark Lewis
• Re: Precomputed constants?
  • From: Zoltan Boszormenyi
• Optimizer internals
  • From: John Vincent
• Re: Is it possible to start two instances of postgresql?
  • From: Bill Moran
• Re: Which processor runs better for Postgresql?
  • From: Vivek Khera
• Re: Is it possible to start two instances of postgresql?
  • From: Dan Harris
• Re: Postgres consuming way too much memory???
  • From: Bruce Momjian
• Re: Which processor runs better for Postgresql?
  • From: Steve Poe
• Re: Postgres consuming way too much memory???
  • From: Mark Lewis
• Re: Which processor runs better for Postgresql?
  • From: Vivek Khera
• Re: Postgres consuming way too much memory???
  • From: Tom Lane
• Re: Postgres consuming way too much memory???
  • From: jody brownell
• Re: Precomputed constants?
  • From: Jim C. Nasby
• Re: Postgres fsync off (not needed) with NetApp
  • From: Jim C. Nasby
• Re: Confirmation of bad query plan generated by 7.4
  • From: Jim C. Nasby
• Re: Postgres consuming way too much memory???
  • From: Tom Lane
• Re: Postgres consuming way too much memory???
  • From: Tom Lane
• Re: Is it possible to start two instances of postgresql?
  • From: Chris Browne
• Re: Postgres consuming way too much memory???
  • From: jody brownell
• Re: How to analyze function performance
  • From: Tom Lane
• Re: How to analyze function performance
  • From: Tomas Vondra
• How to analyze function performance
  • From: Mindaugas
• Re: Postgres consuming way too much memory???
  • From: jody brownell
• Re: Postgres consuming way too much memory???
  • From: jody brownell
• Re: Is it possible to start two instances of postgresql?
  • From: Nis Jorgensen
• Re: Is it possible to start two instances of postgresql?
  • From: kah_hang_ang
• Re: Is it possible to start two instances of postgresql?
  • From: A. Kretschmer
• Re: Is it possible to start two instances of postgresql?
  • From: kah_hang_ang
• Re: Is it possible to start two instances of postgresql?
  • From: A. Kretschmer
• Re: Postgres fsync off (not needed) with NetApp
  • From: Dan Gorman
• Is it possible to start two instances of postgresql?
  • From: kah_hang_ang
• Re: Postgres fsync off (not needed) with NetApp
  • From: Joe Conway
• Re: Postgres fsync off (not needed) with NetApp
  • From: Jonah H. Harris
• Re: Postgres fsync off (not needed) with NetApp
  • From: Jonah H. Harris
• Re: Postgres fsync off (not needed) with NetApp
  • From: Dan Gorman
• Re: Postgres fsync off (not needed) with NetApp
  • From: Jonah H. Harris
• Re: Precomputed constants?
  • From: Zoltan Boszormenyi
• Re: Postgres fsync off (not needed) with NetApp
  • From: Greg Stark
• Re: Confirmation of bad query plan generated by 7.4
  • From: Tom Lane
• Re: Confirmation of bad query plan generated by 7.4
  • From: Jim Nasby
• Re: Effects of cascading references in foreign keys
  • From: Bruce Momjian
• Re: Postgres fsync off (not needed) with NetApp
  • From: Mark Lewis
• Re: Postgres fsync off (not needed) with NetApp
  • From: D'Arcy J.M. Cain
• Postgres fsync off (not needed) with NetApp
  • From: Dan Gorman
• Re: Solaris shared_buffers anomaly?
  • From: Josh Berkus
• Re: Performance of pg_dump on PGSQL 8.0
  • From: Jim C. Nasby
• Re: Performance of pg_dump on PGSQL 8.0
  • From: John Vincent
• Re: Performance of pg_dump on PGSQL 8.0
  • From: John Vincent
• Re: Performance of pg_dump on PGSQL 8.0
  • From: Jim C. Nasby
• Re: Performance of pg_dump on PGSQL 8.0
  • From: Scott Marlowe
• Re: Performance of pg_dump on PGSQL 8.0
  • From: John Vincent
• Re: Performance of pg_dump on PGSQL 8.0
  • From: Scott Marlowe
• Re: Postgres consuming way too much memory???
  • From: Tom Lane
• Re: Which processor runs better for Postgresql?
  • From: Dave Page
• Re: Which processor runs better for Postgresql?
  • From: Scott Marlowe
• Postgres consuming way too much memory???
  • From: jody brownell
• Re: OT - select + must have from - sql standard syntax?
  • From: Antoine
• Re: Which processor runs better for Postgresql?
  • From: Dave Page
• Re: Performance of pg_dump on PGSQL 8.0
  • From: John Vincent
• Re: Performance of pg_dump on PGSQL 8.0
  • From: A.M.
• Re: Performance of pg_dump on PGSQL 8.0
  • From: John Vincent
• Re: Which processor runs better for Postgresql?
  • From: Scott Marlowe
• Re: Solaris shared_buffers anomaly?
  • From: Mischa Sandberg
• Re: Performance of pg_dump on PGSQL 8.0
  • From: Scott Marlowe
• Re: Performance of pg_dump on PGSQL 8.0
  • From: Tom Lane
• Re: Precomputed constants?
  • From: Jim C. Nasby
• Re: how to partition disks
  • From: Jim C. Nasby
• Performance of pg_dump on PGSQL 8.0
  • From: John E. Vincent
• Re: Which processor runs better for Postgresql?
  • From: Steve Poe
• Re: Confirmation of bad query plan generated by 7.4
  • From: Shaun Thomas
• Re: how to partition disks
  • From: Sven Geisler
• Re: how to partition disks
  • From: Richard Broersma Jr
• Re: OT - select + must have from - sql standard syntax?
  • From: Tom Lane
• Re: OT - select + must have from - sql standard syntax?
  • From: Dave Dutcher
• Re: Confirmation of bad query plan generated by 7.4
  • From: Jim C. Nasby
• Re: how to partition disks
  • From: Sven Geisler
• Re: Precomputed constants?
  • From: Böszörményi Zoltán
• Re: how to partition disks
  • From: hubert depesz lubaczewski
• Re: Precomputed constants?
  • From: Volkan YAZICI
• Precomputed constants?
  • From: Böszörményi Zoltán
• Re: how to partition disks
  • From: Sven Geisler
• how to partition disks
  • From: hubert depesz lubaczewski
• Re: OT - select + must have from - sql standard syntax?
  • From: Antoine
• Re: OT - select + must have from - sql standard syntax?
  • From: Greg Stark
• Re: Solaris shared_buffers anomaly?
  • From: Jim C. Nasby
• Re: OT - select + must have from - sql standard syntax?
  • From: Tom Lane
• Re: scaling up postgres
  • From: Tom Lane
• Re: Confirmation of bad query plan generated by 7.4
  • From: Tom Lane
• Re: Solaris shared_buffers anomaly?
  • From: Tom Lane
• Re: Confirmation of bad query plan generated by 7.4
  • From: Tom Lane
• Re: scaling up postgres
  • From: John Vincent
• Re: Solaris shared_buffers anomaly?
  • From: Mark Kirkwood
• Re: Solaris shared_buffers anomaly?
  • From: Mischa Sandberg
• Re: Solaris shared_buffers anomaly?
  • From: Jim C. Nasby
• Re: Solaris shared_buffers anomaly?
  • From: Mischa Sandberg
• Re: Solaris shared_buffers anomaly?
  • From: Mischa Sandberg
• Re: Solaris shared_buffers anomaly?
  • From: Joshua D. Drake
• Re: Confirmation of bad query plan generated by 7.4
  • From: Jim C. Nasby
• Re: Solaris shared_buffers anomaly?
  • From: Jim C. Nasby
• Re: scaling up postgres
  • From: Jim C. Nasby
• Re: Confirmation of bad query plan generated by 7.4
  • From: Shaun Thomas
• Re: Confirmation of bad query plan generated by 7.4
  • From: Jim C. Nasby
• Re: Solaris shared_buffers anomaly?
  • From: Michael Fuhr
• Re: Solaris shared_buffers anomaly?
  • From: Tom Lane
• Re: scaling up postgres
  • From: John Vincent
• Solaris shared_buffers anomaly?
  • From: Mischa Sandberg
• Re: scaling up postgres
  • From: Jim C. Nasby
• Re: Confirmation of bad query plan generated by 7.4
  • From: Tom Lane
• Re: scaling up postgres
  • From: Zydoon
• Re: Confirmation of bad query plan generated by 7.4
  • From: Jim C. Nasby
• Re: scaling up postgres
  • From: John Vincent
• Re: Confirmation of bad query plan generated by 7.4
  • From: Shaun Thomas
• Re: Confirmation of bad query plan generated by 7.4
  • From: Jim C. Nasby
• Re: scaling up postgres
  • From: Jim C. Nasby
• Re: Which processor runs better for Postgresql?
  • From: Jim C. Nasby
• Re: Confirmation of bad query plan generated by 7.4 tree
  • From: Tom Lane
• Re: OT - select + must have from - sql standard syntax?
  • From: Jim C. Nasby
• Re: Confirmation of bad query plan generated by 7.4
  • From: Shaun Thomas
• Re: scaling up postgres
  • From: PFC
• Re: Which processor runs better for Postgresql?
  • From: Dave Page
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Jim C. Nasby
• Re: Which processor runs better for Postgresql?
  • From: Joshua D. Drake
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Jim C. Nasby
• Re: scaling up postgres
  • From: Gavin Hamill
• Re: scaling up postgres
  • From: Scott Marlowe
• Re: scaling up postgres
  • From: Jim C. Nasby
• Re: Which processor runs better for Postgresql?
  • From: Bruce Momjian
• Re: Which processor runs better for Postgresql?
  • From: David Boreham
• Re: Which processor runs better for Postgresql?
  • From: Chris Browne
• Re: Which processor runs better for Postgresql?
  • From: Scott Marlowe
• Re: Confirmation of bad query plan generated by 7.4 tree
  • From: Marcin Mank
• Re: Confirmation of bad query plan generated by 7.4 tree
  • From: Tom Lane
• Which processor runs better for Postgresql?
  • From: Steve Poe
• Confirmation of bad query plan generated by 7.4 tree
  • From: Shaun Thomas
• Re: Placement of 64-bit libraries (offtopic)
  • From: Stephen Frost
• Re: function not called if part of aggregate
  • From: Tom Lane
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: J. Andrew Rogers
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Andreas Pflug
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Sven Geisler
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Luke Lonergan
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Sven Geisler
• OT - select + must have from - sql standard syntax?
  • From: Antoine
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Luke Lonergan
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Christopher Browne
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Sven Geisler
• Re: Interesting slow query
  • From: PFC
• Re: Posrgres speed problem - solved!
  • From: Guido Neitzer
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Luke Lonergan
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: PFC
• Re: Posrgres speed problem - solved!
  • From: Ruben Rubio Rey
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Sven Geisler
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Nis Jorgensen
• Re: Posrgres speed problem - solved?
  • From: Ruben Rubio Rey
• Re: Posrgres speed problem - solved?
  • From: Guido Neitzer
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: J. Andrew Rogers
• Re: Posrgres speed problem - solved?
  • From: Ruben Rubio Rey
• Re: Posrgres speed problem
  • From: Ruben Rubio Rey
• Placement of 64-bit libraries (offtopic)
  • From: Steinar H. Gunderson
• Re: function not called if part of aggregate
  • From: Craig A. James
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Josh Berkus
• Re: scaling up postgres
  • From: Zydoon
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Leigh Dyer
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: David Wheeler
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Luke Lonergan
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Christopher Browne
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Tom Lane
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Christopher Browne
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Alex Turner
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: mark
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Luke Lonergan
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Steve Atkins
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Joshua D. Drake
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Bill Moran
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Stephen Frost
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Tom Lane
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Steve Atkins
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: David Boreham
• Re: 64-bit vs 32-bit performance ... backwards?
  • From: Josh Berkus
• 64-bit vs 32-bit performance ... backwards?
  • From: Anthony Presley
• Re: Interesting slow query
  • From: Tom Lane
• Interesting slow query
  • From: PFC
• Re: Posrgres speed problem
  • From: Sven Geisler
• Re: Posrgres speed problem
  • From: Jim C. Nasby
• Re: Posrgres speed problem
  • From: Jim C. Nasby
• Re: Posrgres speed problem
  • From: Ruben Rubio Rey
• Re: Posrgres speed problem
  • From: Jim C. Nasby
• Re: pgsql_tmp and postgres settings
  • From: Jim C. Nasby
• Re: Posrgres speed problem
  • From: Michael Fuhr
• Re: Posrgres speed problem
  • From: Ruben Rubio Rey
• Re: Posrgres speed problem
  • From: Ruben Rubio Rey
• Re: Posrgres speed problem
  • From: Dave Dutcher
• Posrgres speed problem
  • From: Ruben Rubio Rey
• Re: scaling up postgres
  • From: Sven Geisler
• Re: scaling up postgres
  • From: Alex Stapleton
• Re: scaling up postgres
  • From: Sven Geisler
• Re: pgsql_tmp and postgres settings
  • From: Gourish Singbal
• Re: Variation between query runtimes
  • From: Qingqing Zhou
• Re: scaling up postgres
  • From: Joshua D. Drake
• Re: scaling up postgres
  • From: Mario Splivalo
• Re: scaling up postgres
  • From: Steinar H. Gunderson
• Re: function not called if part of aggregate
  • From: Greg Stark
• Re: function not called if part of aggregate
  • From: Jim C. Nasby
• Re: function not called if part of aggregate
  • From: Tom Lane
• Re: function not called if part of aggregate
  • From: Steinar H. Gunderson
• function not called if part of aggregate
  • From: Craig A. James
• Variation between query runtimes
  • From: John Top-k apad
• FW: pg_xlog on data partition with BBU RAID
  • From: Jim Nasby
• Re: pg_xlog on data partition with BBU RAID
  • From: Scott Marlowe
• pg_xlog on data partition with BBU RAID
  • From: Jim C. Nasby
• Re: pgsql_tmp and postgres settings
  • From: Jim C. Nasby
• Re: Why date index is not used
  • From: Jim C. Nasby
• Re: Regarding pg_dump utility
  • From: Paul S
• pgsql_tmp and postgres settings
  • From: Domenico - Sal. F.lli Riva
• Re: Why date index is not used
  • From: Andrus
• Re: Why date index is not used
  • From: Andrus
• Re: Why date index is not used
  • From: Andrus
• Re: Regarding pg_dump utility
  • From: Christopher Kings-Lynne
• Re: Regarding pg_dump utility
  • From: Christopher Kings-Lynne
• Re: Why date index is not used
  • From: Tom Lane