Postgres Performance Date Index

• Thread Index

• 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
• Re: Why date index is not used
  • From: Jim C. Nasby
• Re: Why date index is not used
  • From: Dave Dutcher
• Re: Why date index is not used
  • From: Tom Lane
• Re: Why date index is not used
  • From: Tomas Vondra
• Re: Why date index is not used
  • From: Tomas Vondra
• Why date index is not used
  • From: Andrus
• Re: JOIN with inherited table ignores indexes
  • From: Andreas Pflug
• Re: Regarding pg_dump utility
  • From: Alvaro Herrera
• Re: Regarding pg_dump utility
  • From: Jim C. Nasby
• Re: Regarding pg_dump utility
  • From: Andreas Pflug
• Re: Regarding pg_dump utility
  • From: Alvaro Herrera
• Re: JOIN with inherited table ignores indexes
  • From: Tom Lane
• Re: Regarding pg_dump utility
  • From: Geoffrey
• Re: JOIN with inherited table ignores indexes
  • From: Jim C. Nasby
• Re: Regarding pg_dump utility
  • From: Jim C. Nasby
• Re: Regarding pg_dump utility
  • From: Tom Lane
• Re: Regarding ALTER Command
  • From: Tom Lane
• JOIN with inherited table ignores indexes
  • From: Andreas Pflug
• Regarding pg_dump utility
  • From: soni de
• Re: Regarding ALTER Command
  • From: soni de
• Re: Curious sorting puzzle
  • From: Ivan Voras
• Re: vacuuming problems continued
  • From: Jim C. Nasby
• Re: Curious sorting puzzle
  • From: Tom Lane
• Re: vacuuming problems continued
  • From: Antoine
• Curious sorting puzzle
  • From: Ivan Voras
• Re: Regarding ALTER Command
  • From: Jim C. Nasby
• Regarding ALTER Command
  • From: soni de
• Re: Some queries starting to hang
  • From: Simon Riggs
• Re: lowering priority automatically at connection
  • From: Ron Mayer
• Re: Some queries starting to hang
  • From: Scott Marlowe
• Re: Some queries starting to hang
  • From: Tom Lane
• Re: Some queries starting to hang
  • From: Scott Marlowe
• Re: Some queries starting to hang
  • From: Jim C. Nasby
• Re: vacuuming problems continued
  • From: Mischa Sandberg
• Re: vacuuming problems continued
  • From: Joshua D. Drake
• Re: vacuuming problems continued
  • From: Mischa Sandberg
• Re: Some queries starting to hang
  • From: Scott Marlowe
• Re: Some queries starting to hang
  • From: Craig A. James
• Re: Some queries starting to hang
  • From: Craig A. James
• Re: Some queries starting to hang
  • From: Andrew Sullivan
• Re: Some queries starting to hang
  • From: Tom Lane
• Re: Some queries starting to hang
  • From: Greg Stark
• Re: Some queries starting to hang
  • From: A.M.
• Re: Some queries starting to hang
  • From: Andrew Sullivan
• Re: Some queries starting to hang
  • From: A.M.
• Re: Some queries starting to hang
  • From: Jim C. Nasby
• Re: Some queries starting to hang
  • From: Tom Lane
• Re: Some queries starting to hang
  • From: Jim C. Nasby
• Re: Some queries starting to hang
  • From: Simon Riggs
• Re: Some queries starting to hang
  • From: Tom Lane
• Re: Some queries starting to hang
  • From: Simon Riggs
• Re: How to force Postgres to use index on ILIKE
  • From: Tom Lane
• Re: How to force Postgres to use index on ILIKE
  • From: Andrus
• Re: Problem: query becomes slow when calling a fast user defined function.
  • From: Tom Lane
• Problem: query becomes slow when calling a fast user defined function.
  • From: Dan Libby
• Re: Some queries starting to hang
  • From: Chris Beecroft
• Re: How to force Postgres to use index on ILIKE
  • From: Josh Berkus
• Re: Some queries starting to hang
  • From: Tom Lane
• Re: vacuuming problems continued
  • From: Andrew Sullivan
• Re: Some queries starting to hang
  • From: Chris Beecroft
• Re: Some queries starting to hang
  • From: Andrew Sullivan
• Re: Some queries starting to hang
  • From: Tom Lane
• Re: Some queries starting to hang
  • From: Andrew Sullivan
• How to force Postgres to use index on ILIKE
  • From: Andrus
• Some queries starting to hang
  • From: Chris Beecroft
• Re: Bulk loading/merging
  • From: Jim C. Nasby
• Re: help me problems with pg_clog file
  • From: Jim C. Nasby
• Re: vacuuming problems continued
  • From: Jim C. Nasby
• Re: How can I make this query faster (resend)
  • From: Jim C. Nasby
• psql -A (unaligned format) eats too much memory
  • From: Zoltan Boszormenyi
• Re: psql -A (unaligned format) eats too much memory
  • From: Zoltan Boszormenyi
• Re: Bulk loading/merging
  • From: Ahmad Fajar
• Re: INSERT OR UPDATE WITHOUT SELECT
  • From: A. Kretschmer
• Re: RES: Initial database loading and IDE x SCSI
  • From: Mark Kirkwood
• Re: RES: Initial database loading and IDE x SCSI
  • From: Bruce Momjian
• Re: scaling up postgres
  • From: Neil Saunders
• Re: scaling up postgres
  • From: David Boreham
• Re: scaling up postgres
  • From: Tom Lane
• Re: scaling up postgres
  • From: David Boreham
• Re: Répondre
  • From: Steinar H. Gunderson
• Re: scaling up postgres
  • From: PFC
• Re: scaling up postgres
  • From: Steinar H. Gunderson
• scaling up postgres
  • From: fzied
• Re: RES: Initial database loading and IDE x SCSI
  • From: Mark Kirkwood
• RES: RES: RES: Initial database loading and IDE x SCSI
  • From: carlosreimer
• Re: RES: RES: Initial database loading and IDE x SCSI
  • From: Mark Lewis
• RES: RES: Initial database loading and IDE x SCSI
  • From: carlosreimer
• Re: RES: Initial database loading and IDE x SCSI
  • From: Mark Lewis
• RES: Initial database loading and IDE x SCSI
  • From: carlosreimer
• Re: Initial database loading and IDE x SCSI
  • From: Tom Lane
• Re: Initial database loading and IDE x SCSI
  • From: Mark Lewis
• Re: Initial database loading and IDE x SCSI
  • From: Scott Marlowe
• Initial database loading and IDE x SCSI
  • From: carlosreimer
• Re: pg_dump issue
  • From: Evgeny Gridasov
• Re: help me problems with pg_clog file
  • From: Gourish Singbal
• Re: Bulk loading/merging
  • From: Michael Artz
• help me problems with pg_clog file
  • From: Joao
• Re: vacuuming problems continued
  • From: Tom Lane
• vacuuming problems continued
  • From: Antoine
• Re: App very unresponsive while performing simple update
  • From: Greg Stark
• Re: App very unresponsive while performing simple update
  • From: Jim C. Nasby
• Re: App very unresponsive while performing simple update
  • From: Jan de Visser
• Re: App very unresponsive while performing simple update
  • From: Brendan Duddridge
• Re: App very unresponsive while performing simple update
  • From: Greg Stark
• Re: App very unresponsive while performing simple update
  • From: Bruno Wolff III
• Re: App very unresponsive while performing simple update
  • From: Jan de Visser
• Re: Speedup hint needed, if available? :)
  • From: Nis Jorgensen
• Re: App very unresponsive while performing simple update
  • From: Brendan Duddridge
• Re: INSERT OU UPDATE WITHOUT SELECT?
  • From: Jim C. Nasby
• Re: App very unresponsive while performing simple update
  • From: Jim C. Nasby
• Re: Why the 8.1 plan is worst than 7.4?
  • From: Tom Lane
• Re: Query performance
  • From: Christopher Kings-Lynne
• Re: Bulk loading/merging
  • From: Jim C. Nasby
• Re: Why the 8.1 plan is worst than 7.4?
  • From: Jim C. Nasby
• Re: INSERT OU UPDATE WITHOUT SELECT?
  • From: D'Arcy J.M. Cain
• Re: INSERT OU UPDATE WITHOUT SELECT?
  • From: Dave Dutcher
• Re: INSERT OU UPDATE WITHOUT SELECT?
  • From: Alvaro Herrera
• Re: Optimizing a huge_table/tiny_table join
  • From: PFC
• Re: INSERT OU UPDATE WITHOUT SELECT?
  • From: PFC
• Re: Getting even more insert performance (250m+rows/day)
  • From: Daniel J. Luke
• Re: Split select completes, single select doesn't and
  • From: Ragnar
• Re: INSERT OU UPDATE WITHOUT SELECT?
  • From: Jonah H. Harris
• Re: Adding and filling new column on big table
  • From: Francisco Reyes
• INSERT OR UPDATE WITHOUT SELECT
  • From: wmiro
• Re: Adding and filling new column on big table
  • From: PFC
• Re: Adding and filling new column on big table
  • From: Scott Marlowe
• Re: Adding and filling new column on big table
  • From: Jonathan Blitz
• Re: Getting even more insert performance (250m+rows/day)
  • From: Daniel J. Luke
• INSERT OU UPDATE WITHOUT SELECT?
  • From: Waldomiro
• Re: Adding and filling new column on big table
  • From: Francisco Reyes
• Re: pg_dump issue
  • From: mcelroy, tim
• Re: pg_dump issue
  • From: Tom Lane
• Re: Adding and filling new column on big table
  • From: Jonathan Blitz
• Re: Adding and filling new column on big table
  • From: Francisco Reyes
• Re: pg_dump issue
  • From: mcelroy, tim
• Re: Speedup hint needed, if available? :)
  • From: Mario Splivalo
• Re: pg_dump issue
  • From: Tom Lane
• Re: Speedup hint needed, if available? :)
  • From: Tom Lane
• pg_dump issue
  • From: mcelroy, tim
• Speedup hint needed, if available? :)
  • From: Mario Splivalo
• Re: Selects query stats?
  • From: Alvis Tunkelis
• Re: Adding and filling new column on big table
  • From: Jonathan Blitz
• Re: Selects query stats?
  • From: Francisco Reyes
• Re: Adding and filling new column on big table
  • From: Francisco Reyes
• Split select completes, single select doesn't and becomes IO bound!
  • From: Anthony Ransley
• Re: select with "like" from another table
  • From: Anton Maksimenkov
• Re: How can I make this query faster (resend)
  • From: Cstdenis
• Re: How can I make this query faster (resend)
  • From: Cstdenis
• Re: Getting even more insert performance (250m+rows/day)
  • From: Markus Schaber
• Re: select with "like" from another table
  • From: chris smith
• select with "like" from another table
  • From: Anton Maksimenkov
• Re: App very unresponsive while performing simple update
  • From: Greg Stark
• Re: App very unresponsive while performing simple update
  • From: Greg Stark
• Re: Query performance
  • From: Erwin Brandstetter
• Re: Query performance
  • From: Erwin Brandstetter
• Re: App very unresponsive while performing simple update
  • From: Tom Lane
• Re: App very unresponsive while performing simple update
  • From: Brendan Duddridge
• Re: App very unresponsive while performing simple update
  • From: Greg Stark
• Re: App very unresponsive while performing simple update
  • From: Tom Lane
• Re: How can I make this query faster (resend)
  • From: Cstdenis
• Re: App very unresponsive while performing simple update
  • From: Greg Stark
• Re: App very unresponsive while performing simple update
  • From: Brendan Duddridge
• App very unresponsive while performing simple update
  • From: Brendan Duddridge
• Re: is it possible to make this faster?
  • From: Mark Kirkwood
• Re: Speed Up Offset and Limit Clause
  • From: PFC
• Re: is it possible to make this faster?
  • From: Tom Lane
• Re: is it possible to make this faster?
  • From: Merlin Moncure
• Re: Bulk loading/merging
  • From: Worky Workerson
• Bulk loading/merging
  • From: Worky Workerson
• Re: is it possible to make this faster?
  • From: Tom Lane
• Re: is it possible to make this faster?
  • From: Merlin Moncure
• Re: is it possible to make this faster?
  • From: Tom Lane
• Re: is it possible to make this faster?
  • From: Merlin Moncure
• Re: column totals
  • From: Ragnar
• Re: is it possible to make this faster?
  • From: Tom Lane
• Re: column totals
  • From: James Neethling
• Why the 8.1 plan is worst than 7.4?
  • From: wmiro
• column totals
  • From: James Neethling
• Re: is it possible to make this faster?
  • From: Merlin Moncure
• Re: is it possible to make this faster?
  • From: Tom Lane
• Re: is it possible to make this faster?
  • From: Jeff -
• Re: lowering priority automatically at connection
  • From: Christopher Kings-Lynne
• Re: Optimizing a huge_table/tiny_table join
  • From: Mark Kirkwood
• Re: is it possible to make this faster?
  • From: Tom Lane
• Re: is it possible to make this faster?
  • From: Jim Nasby
• Re: Optimizing a huge_table/tiny_table join
  • From: Jim Nasby
• Re: is it possible to make this faster?
  • From: Mark Lewis
• Re: is it possible to make this faster?
  • From: Scott Marlowe
• Re: is it possible to make this faster?
  • From: Tom Lane
• Re: is it possible to make this faster?
  • From: Steinar H. Gunderson
• Re: is it possible to make this faster?
  • From: Merlin Moncure
• Re: is it possible to make this faster?
  • From: Tom Lane
• Re: is it possible to make this faster?
  • From: Bruno Wolff III
• Re: is it possible to make this faster?
  • From: Alan Hodgson
• Re: is it possible to make this faster?
  • From: Steinar H. Gunderson
• Re: is it possible to make this faster?
  • From: Merlin Moncure
• Re: is it possible to make this faster?
  • From: Bruno Wolff III
• is it possible to make this faster?
  • From: Merlin Moncure
• Re: Optimizing a huge_table/tiny_table join
  • From: Dawid Kuroczko
• Re: lowering priority automatically at connection
  • From: Michael Fuhr
• Re: Optimizing a huge_table/tiny_table join
  • From: Andrew Sullivan
• Re: lowering priority automatically at connection
  • From: Chris Mair
• Re: Optimizing a huge_table/tiny_table join
  • From: kynn
• Re: lowering priority automatically at connection
  • From: Tom Lane
• Re: Optimizing a huge_table/tiny_table join
  • From: Kynn Jones
• lowering priority automatically at connection
  • From: Chris Mair
• Re: Getting even more insert performance (250m+rows/day)
  • From: Ian Westmacott
• Re: Optimizing a huge_table/tiny_table join
  • From: Tom Lane
• Re: Optimizing a huge_table/tiny_table join
  • From: Joshua D. Drake
• Optimizing a huge_table/tiny_table join
  • From: kynn
• Re: Selects query stats?
  • From: Jim C. Nasby
• Re: Getting even more insert performance (250m+rows/day)
  • From: Jim C. Nasby
• Re: Getting even more insert performance (250m+rows/day)
  • From: Daniel J. Luke
• Re: Getting even more insert performance (250m+rows/day)
  • From: Larry Rosenman
• Re: Getting even more insert performance (250m+rows/day)
  • From: Daniel J. Luke
• Re: Getting even more insert performance (250m+rows/day)
  • From: Daniel J. Luke
• Re: Getting even more insert performance (250m+rows/day)
  • From: Mark Lewis
• Re: Getting even more insert performance (250m+rows/day)
  • From: Steinar H. Gunderson
• Re: Getting even more insert performance (250m+rows/day)
  • From: Larry Rosenman
• Re: Getting even more insert performance (250m+rows/day)
  • From: Daniel J. Luke
• Re: Getting even more insert performance (250m+rows/day)
  • From: Daniel J. Luke
• Re: Getting even more insert performance (250m+rows/day)
  • From: Steinar H. Gunderson
• Re: Getting even more insert performance (250m+rows/day)
  • From: Dave Dutcher
• Getting even more insert performance (250m+rows/day)
  • From: Daniel J. Luke
• Optimizing a huge_table/tiny_table join
  • From: kynn
• Optimizing a huge_table/tiny_table join
  • From: kynn
• Re: Selects query stats?
  • From: Robin Ericsson
• compiling source code!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  • From: sibel karaasma
• Re: Selects query stats?
  • From: Mischa Sandberg
• Re: Selects query stats?
  • From: Simon Riggs
• Re: Selects query stats?
  • From: Guillaume Smet
• Re: Selects query stats?
  • From: Jim C. Nasby
• Re: Selects query stats?
  • From: Tom Lane
• Re: Selects query stats?
  • From: Alvaro Herrera
• Re: Selects query stats?
  • From: Tom Lane
• Re: Selects query stats?
  • From: Dan Gorman
• Re: Selects query stats?
  • From: Simon Riggs
• Re: Selects query stats?
  • From: Jim C. Nasby
• Re: Selects query stats?
  • From: Dan Gorman
• Re: Selects query stats?
  • From: Mischa Sandberg
• Re: Selects query stats?
  • From: Dan Gorman
• Re: Selects query stats?
  • From: Mischa Sandberg
• Selects query stats?
  • From: Dan Gorman
• Re: slow query using sub select
  • From: Tim Jones
• Re: Query performance
  • From: Antonio Batovanja
• Re: Query performance
  • From: Steinar H. Gunderson
• Re: slow query using sub select
  • From: Jonathan Blitz
• Re: slow query using sub select
  • From: Tom Lane
• slow query using sub select
  • From: Tim Jones
• Re: Query hanging/not finishing inconsistently
  • From: Meetesh Karia
• Re: Query hanging/not finishing inconsistently
  • From: Craig A. James
• Query hanging/not finishing inconsistently
  • From: Meetesh Karia
• Re: Performs WAY better with enable_seqscan = off
  • From: Jim C. Nasby
• Re: How can I make this query faster (resend)
  • From: Markus Schaber
• Re: Performs WAY better with enable_seqscan = off
  • From: Jim C. Nasby
• Re: utilizing multiple disks for i/o performance
  • From: Jim C. Nasby
• Re: How can I make this query faster (resend)
  • From: Jim C. Nasby
• Re: utilizing multiple disks for i/o performance
  • From: Scott Marlowe
• Re: Benchmarking Function
  • From: David Wheeler
• Re: Performs WAY better with enable_seqscan = off
  • From: Brendan Duddridge
• Re: Benchmarking Function
  • From: Josh Berkus
• Re: Performs WAY better with enable_seqscan = off
  • From: Ragnar
• Performs WAY better with enable_seqscan = off
  • From: Brendan Duddridge
• Benchmarking Function
  • From: David Wheeler
• utilizing multiple disks for i/o performance
  • From: Kenji Morishige
• How can I make this query faster (resend)
  • From: Cstdenis
• Re: why is bitmap index chosen for this query?
  • From: Jim C. Nasby
• Re: Performance/Maintenance test result collection
  • From: Jim C. Nasby
• Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle
  • From: Jim C. Nasby
• Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle
  • From: Jim C. Nasby
• Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle 10g2
  • From: Tom Lane
• Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle 10g2
  • From: Olivier Andreotti
• Re: why is bitmap index chosen for this query?
  • From: Stephen Byers
• Re: why is bitmap index chosen for this query?
  • From: Steinar H. Gunderson
• Re: why is bitmap index chosen for this query?
  • From: Stephen Byers
• Re: why is bitmap index chosen for this query?
  • From: Steinar H. Gunderson
• Re: why is bitmap index chosen for this query?
  • From: Stephen Byers
• Re: why is bitmap index chosen for this query?
  • From: Tom Lane
• Re: why is bitmap index chosen for this query?
  • From: Steinar H. Gunderson
• Re: why is bitmap index chosen for this query?
  • From: Stephen Byers
• Re: SQL CPU time usage
  • From: Ivan Zolotukhin
• Re: why is bitmap index chosen for this query?
  • From: Steinar H. Gunderson
• why is bitmap index chosen for this query?
  • From: Stephen Byers
• Re: Performance/Maintenance test result collection
  • From: Chris Mckenzie
• Re: SQL CPU time usage
  • From: Ruben Rubio Rey
• Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle 10g2
  • From: Tom Lane