Postgres Performance Date Index

• Thread Index

• Lots of "semop" calls under load
  • From: Albe Laurenz
• Re: ER diagram tool
  • From: sathiya psql
• Re: ER diagram tool
  • From: Jurgen Haan
• Re: 8.3 write performance
  • From: Enrico Sirola
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Greg Smith
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Jesper Krogh
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Jesper Krogh
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Scott Marlowe
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Scott Marlowe
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Scott Marlowe
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Scott Marlowe
• Re: Recomendations on raid controllers raid 1+0
  • From: Scott Marlowe
• Re: temp tables
  • From: Tom Lane
• Re: Recomendations on raid controllers raid 1+0
  • From: Leigh Dyer
• temp tables
  • From: James Mansion
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: justin
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Greg Smith
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Joshua D. Drake
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: justin
• Re: ER diagram tool
  • From: Andrej Ricnik-Bay
• Re: Recomendations on raid controllers raid 1+0
  • From: Glyn Astill
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Greg Smith
• Re: Recomendations on raid controllers raid 1+0
  • From: Guillaume Smet
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Craig James
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Craig James
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Craig James
• Re: Repeated execution of identical subqueries
  • From: Craig James
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin Graf
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Will Weaver
• Re: ER diagram tool
  • From: A. Kretschmer
• ER diagram tool
  • From: sathiya psql
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Doug Knight
• Recomendations on raid controllers raid 1+0
  • From: Glyn Astill
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin Graf
• Re: partial index + select query performance
  • From: A. Kretschmer
• partial index + select query performance
  • From: petchimuthu lingam
• Re: Repeated execution of identical subqueries
  • From: Craig Ringer
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Joshua D. Drake
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Scott Marlowe
• Re: Repeated execution of identical subqueries
  • From: Tom Lane
• Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Craig James
• Repeated execution of identical subqueries
  • From: Craig Ringer
• Re: Are piped columns indexable
  • From: Merlin Moncure
• Are piped columns indexable
  • From: Mark Steben
• Re: Hardware question for a DB server
  • From: Greg Smith
• Re: Hardware question for a DB server
  • From: Pascal Cohen
• Re: Hardware question for a DB server
  • From: Mark Lewis
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Bruce Momjian
• Hardware question for a DB server
  • From: Pascal Cohen
• 8.3 write performance
  • From: Enrico Sirola
• Re: migration of 7.4 to 8.1
  • From: Vivek Khera
• Re: migration of 7.4 to 8.1
  • From: Steinar H. Gunderson
• Re: migration of 7.4 to 8.1
  • From: sathiya psql
• Re: migration of 7.4 to 8.1
  • From: Chris
• Re: migration of 7.4 to 8.1
  • From: david
• Re: migration of 7.4 to 8.1
  • From: david
• Re: migration of 7.4 to 8.1
  • From: Craig Ringer
• Re: migration of 7.4 to 8.1
  • From: david
• Re: migration of 7.4 to 8.1
  • From: sathiya psql
• Re: migration of 7.4 to 8.1
  • From: Craig Ringer
• Re: migration of 7.4 to 8.1
  • From: sathiya psql
• Re: migration of 7.4 to 8.1
  • From: Craig Ringer
• Re: migration of 7.4 to 8.1
  • From: Chris
• Re: migration of 7.4 to 8.1
  • From: sathiya psql
• Re: migration of 7.4 to 8.1
  • From: sathiya psql
• Re: migration of 7.4 to 8.1
  • From: Craig Ringer
• migration of 7.4 to 8.1
  • From: sathiya psql
• Re: list user created triggers
  • From: sathiya psql
• Re: list user created triggers
  • From: sathiya psql
• Re: how many index can have????
  • From: Craig Ringer
• Re: Joins and DELETE FROM
  • From: Kynn Jones
• Re: count * performance issue
  • From: Andrew Sullivan
• Re: count * performance issue
  • From: Heikki Linnakangas
• Re: count * performance issue
  • From: Matthew
• Re: count * performance issue
  • From: Tino Wildenhain
• Re: count * performance issue
  • From: Matthew
• Re: how many index can have????
  • From: Dave Cramer
• list user created triggers
  • From: sathiya psql
• Re: count * performance issue
  • From: Bill Moran
• how many index can have????
  • From: petchimuthu lingam
• Re: Very slow (2 tuples/second) sequential scan afterbulk insert; speed returns to ~500 tuples/second after commit
  • From: Heikki Linnakangas
• Re: count * performance issue
  • From: Albert Cervera Areny
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Pavan Deolasee
• Re: UPDATE 66k rows too slow
  • From: Greg Smith
• Re: count * performance issue
  • From: Scott Marlowe
• Re: count * performance issue
  • From: Joshua D. Drake
• Re: count * performance issue
  • From: Mark Mielke
• Re: count * performance issue
  • From: Robins Tharakan
• Re: Nested loop vs merge join: inconsistencies between estimated and actual time
  • From: Vlad Arkhipov
• Re: UPDATE 66k rows too slow
  • From: Miguel Arroz
• Re: UPDATE 66k rows too slow
  • From: Joshua D. Drake
• Re: UPDATE 66k rows too slow
  • From: Miguel Arroz
• Re: UPDATE 66k rows too slow
  • From: Joshua D. Drake
• Re: UPDATE 66k rows too slow
  • From: Miguel Arroz
• Re: count * performance issue
  • From: Greg Smith
• Re: count * performance issue
  • From: Scott Marlowe
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Simon Riggs
• Re: count * performance issue
  • From: Greg Smith
• Re: count * performance issue
  • From: Bill Moran
• Re: count * performance issue
  • From: Joe Mirabal
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Rainer Pruy
• Re: multi-threaded pgloader needs your tests
  • From: Dimitri Fontaine
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Tom Lane
• Re: count * performance issue
  • From: Gregory Stark
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Craig Ringer
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Heikki Linnakangas
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Tom Lane
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Heikki Linnakangas
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Craig Ringer
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Tom Lane
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Craig Ringer
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Craig Ringer
• Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Heikki Linnakangas
• Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
  • From: Craig Ringer
• Utility functions for enabling/disabling fkey triggers
  • From: Craig Ringer
• Re: UPDATE 66k rows too slow
  • From: Greg Smith
• Re: UPDATE 66k rows too slow
  • From: Tom Lane
• Re: UPDATE 66k rows too slow
  • From: andrew
• UPDATE 66k rows too slow
  • From: Miguel Arroz
• Re: Joins and DELETE FROM
  • From: Heikki Linnakangas
• Re: Joins and DELETE FROM
  • From: Tom Lane
• Re: Joins and DELETE FROM
  • From: Kynn Jones
• Re: Joins and DELETE FROM
  • From: Heikki Linnakangas
• Joins and DELETE FROM
  • From: Kynn Jones
• Re: Re: Confirmação de envio / Sending confirmation (captchaid:13266b402f09)
  • From: Alvaro Herrera
• Re: count * performance issue
  • From: Arjen van der Meijden
• Re: count * performance issue
  • From: paul rivers
• Re: count * performance issue
  • From: Tom Lane
• Re: count * performance issue
  • From: Mark Mielke
• Re: count * performance issue
  • From: Greg Smith
• Re: Confirmação de envio / Sending confirmation (captchaid:13266b402f09)
  • From: petchimuthu lingam
• Confirmação de envio / Sending confirmation (captchaid:13266b402bd3)
  • From: petchimuthu lingam
• join query performance
  • From: petchimuthu lingam
• Re: count * performance issue
  • From: Tom Lane
• Re: count * performance issue
  • From: Josh Berkus
• Re: Why the difference in plans ?
  • From: Josh Berkus
• Re: count * performance issue
  • From: Mark Kirkwood
• Re: Effects of cascading references in foreign keys
  • From: Bruce Momjian
• Re: Toast space grows
  • From: Pavel Rotek
• Re: Toast space grows
  • From: Bill Moran
• Re: Toast space grows
  • From: Tom Lane
• Re: Toast space grows
  • From: Pavel Rotek
• Re: Toast space grows
  • From: Pavel Rotek
• Re: Toast space grows
  • From: Matthew
• Re: Toast space grows
  • From: Pavel Rotek
• Re: Toast space grows
  • From: Matthew
• Re: Toast space grows
  • From: Tom Lane
• Re: Toast space grows
  • From: Alvaro Herrera
• Re: postgresql Explain command output
  • From: RaviRam Kolipaka
• Re: Toast space grows
  • From: Pavel Rotek
• Re: Toast space grows
  • From: Bill Moran
• Re: Why the difference in plans ?
  • From: Dave Cramer
• Re: Why the difference in plans ?
  • From: Dave Cramer
• Re: Toast space grows
  • From: Pavel Rotek
• Re: Toast space grows
  • From: Richard Huxton
• Re: Improve Full text rank in a query
  • From: Oleg Bartunov
• Toast space grows
  • From: Pavel Rotek
• Re: Nested loop vs merge join: inconsistencies between estimated and actual time
  • From: Tom Lane
• Nested loop vs merge join: inconsistencies between estimated and actual time
  • From: Vlad Arkhipov
• Re: Improve Full text rank in a query
  • From: Tom Lane
• Re: count * performance issue
  • From: paul rivers
• database design for large data.
  • From: shilpa.raghavendra
• Improve Full text rank in a query
  • From: b wragg
• Re: count * performance issue
  • From: Craig James
• Re: count * performance issue
  • From: Mark Kirkwood
• Re: Why the difference in plans ?
  • From: Stephen Denne
• Re: Why the difference in plans ?
  • From: Dave Cramer
• Re: Why the difference in plans ?
  • From: Stephen Denne
• Re: More shared buffers causes lower performances
  • From: Bruce Momjian
• Re: Why the difference in plans ?
  • From: Dave Cramer
• Re: Performance of aggregates over set-returning functions
  • From: Bruce Momjian
• Re: Performance of aggregates over set-returning functions
  • From: Tom Lane
• Re: count * performance issue
  • From: Tom Lane
• Re: Why the difference in plans ?
  • From: Josh Berkus
• Re: Performance of aggregates over set-returning functions
  • From: Bruce Momjian
• Re: count * performance issue
  • From: D'Arcy J.M. Cain
• Re: oid...any optimizations
  • From: Joshua D. Drake
• Re: count * performance issue
  • From: Mark Lewis
• Re: count * performance issue
  • From: Dave Page
• Re: count * performance issue
  • From: Greg Smith
• Re: count * performance issue
  • From: Bill Moran
• Re: count * performance issue
  • From: Steinar H. Gunderson
• Re: count * performance issue
  • From: Bruce Momjian
• Re: count * performance issue
  • From: Craig James
• Re: postgresql Explain command output
  • From: Greg Smith
• Re: postgresql Explain command output
  • From: Tom Lane
• Re: count * performance issue
  • From: Greg Smith
• Re: count * performance issue
  • From: Greg Smith
• Re: count * performance issue
  • From: Mark Mielke
• Re: postgresql Explain command output
  • From: Greg Smith
• Re: count * performance issue
  • From: Alvaro Herrera
• Re: count * performance issue
  • From: A. Kretschmer
• Re: count * performance issue
  • From: Harald Armin Massa
• Re: count * performance issue
  • From: sathiya psql
• Re: count * performance issue
  • From: Dave Cramer
• Re: count * performance issue
  • From: Dave Cramer
• index usage makes problem
  • From: sathiya psql
• Re: oid...any optimizations
  • From: Theo Kramer
• Re: count * performance issue
  • From: A. Kretschmer
• Re: oid...any optimizations
  • From: sathiya psql
• Re: oid...any optimizations
  • From: Joshua D. Drake
• Re: count * performance issue
  • From: sathiya psql
• oid...any optimizations
  • From: sathiya psql
• Re: count * performance issue
  • From: A. Kretschmer
• Re: count * performance issue
  • From: A. Kretschmer
• Fwd: count * performance issue
  • From: sathiya psql
• Re: count * performance issue
  • From: sathiya psql
• Re: count * performance issue
  • From: A. Kretschmer
• Re: count * performance issue
  • From: Shoaib Mir
• Re: count * performance issue
  • From: sathiya psql
• Re: count * performance issue
  • From: Mark Mielke
• Re: count * performance issue
  • From: Shoaib Mir
• Re: count * performance issue
  • From: sathiya psql
• Re: count * performance issue
  • From: Shoaib Mir
• postgresql Explain command output
  • From: RaviRam Kolipaka
• Re: count * performance issue
  • From: A. Kretschmer
• Confirmação de envio / Sending confirmation (captchaid:13266b2056e4)
  • From: petchimuthu lingam
• Re: count * performance issue
  • From: Chris
• Re: Confirmação de envio / Sending confirmation (captchaid:13266b20536d)
  • From: Chris
• count * performance issue
  • From: sathiya psql
• Confirmação de envio / Sending confirmation (captchaid:13266b20536d)
  • From: petchimuthu lingam
• Confirmação de envio / Sending confirmation (captchaid:13266b203e23)
  • From: petchimuthu lingam
• Confirmação de envio / Sending confirmation (captchaid:13266b203c28)
  • From: petchimuthu lingam
• Confirmação de envio / Sending confirmation (captchaid:13266b1124bc)
  • From: petchimuthu lingam
• Why the difference in plans ?
  • From: Dave Cramer
• Re: postgresql performance
  • From: Bill Moran
• Re: postgresql performance
  • From: Kevin Grittner
• Re: postgresql performance
  • From: Dave Dutcher
• Re: PostgreSQL performance on a virtual host
  • From: Ivan Zolotukhin
• Re: PostgreSQL performance on a virtual host
  • From: Bill Moran
• Re: PostgreSQL performance on a virtual host
  • From: Ivan Zolotukhin
• Re: PostgreSQL performance on a virtual host
  • From: Dave Cramer
• Re: postgresql performance
  • From: Claus Guttesen
• Re: postgresql performance
  • From: Franck Routier
• Confirmação de envio / Sending confirmation (captchaid:13266b111e1d)
  • From: petchimuthu lingam
• Re: postgresql performance
  • From: Steinar H. Gunderson
• postgresql performance
  • From: SPMLINGAM
• Re: PostgreSQL performance on a virtual host
  • From: Moritz Onken
• Re: Optimisation help
  • From: dforums
• Re: Optimisation help
  • From: Erik Jones
• Re: Optimisation help
  • From: dforums
• Re: Optimisation help
  • From: Steinar H. Gunderson
• Re: Optimisation help
  • From: dforums
• Re: Optimisation help
  • From: Greg Smith
• Re: Optimisation help
  • From: dforums
• Re: Optimisation help
  • From: dforums
• Re: Optimisation help
  • From: Alan Hodgson
• Optimisation help
  • From: dforums
• Re: Ramifications of turning off Nested Loops for slow queries
  • From: Chris Kratz
• Re: Ramifications of turning off Nested Loops for slow queries
  • From: Chris Kratz
• Re: Ramifications of turning off Nested Loops for slow queries
  • From: Tom Lane
• Re: Performance tuning on FreeBSD
  • From: Greg Smith
• Re: Ramifications of turning off Nested Loops for slow queries
  • From: Kevin Grittner
• PostgreSQL performance on a virtual host
  • From: Theo Kramer
• Re: How to allocate 8 disks
  • From: Shane Ambler
• Ramifications of turning off Nested Loops for slow queries
  • From: Chris Kratz
• Re: Performance tuning on FreeBSD
  • From: Matthew
• Re: Performance tuning on FreeBSD
  • From: Ivan Voras
• Re: Performance problems deleting data
  • From: Alvaro Herrera
• Re: Performance tuning on FreeBSD
  • From: Ivan Voras
• Re: How to allocate 8 disks
  • From: Ivan Voras
• Re: Performance tuning on FreeBSD
  • From: Greg Smith
• Re: Performance tuning on FreeBSD
  • From: alan bryan
• Re: Performance problems deleting data
  • From: Rafael Martinez
• Re: Performance tuning on FreeBSD
  • From: Greg Smith
• Re: Performance tuning on FreeBSD
  • From: alan bryan
• Re: Performance tuning on FreeBSD
  • From: Bill Moran
• Performance tuning on FreeBSD
  • From: alan bryan
• Re: How to choose a disc array for Postgresql?
  • From: Ron Mayer
• Re: Performance problems deleting data
  • From: Tom Lane
• Re: which is more important? freq of checkpoints or the duration of them?
  • From: Greg Smith
• Re: which is more important? freq of checkpoints or the duration of them?
  • From: Greg Smith
• Re: which is more important? freq of checkpoints or the duration of them?
  • From: Chris Browne
• Re: How to allocate 8 disks
  • From: Scott Marlowe
• Performance problems deleting data
  • From: Rafael Martinez
• Re: which is more important? freq of checkpoints or the duration of them?
  • From: Scott Marlowe
• Re: How to allocate 8 disks
  • From: Mark Mielke
• Re: How to choose a disc array for Postgresql?
  • From: Vivek Khera
• Re: How to allocate 8 disks
  • From: Matthew
• Re: How to allocate 8 disks
  • From: Craig James
• Re: How to allocate 8 disks
  • From: Mark Mielke
• Re: How to choose a disc array for Postgresql?
  • From: Vivek Khera
• Re: How to choose a disc array for Postgresql?
  • From: Vivek Khera
• which is more important? freq of checkpoints or the duration of them?
  • From: Douglas J Hunley
• Re: How to allocate 8 disks
  • From: Matthew
• Re: How to choose a disc array for Postgresql?
  • From: Greg Smith
• Re: How to choose a disc array for Postgresql?
  • From: Scott Marlowe
• Re: How to choose a disc array for Postgresql?
  • From: Joshua D. Drake
• Re: How to choose a disc array for Postgresql?
  • From: Steve Poe
• Re: How to choose a disc array for Postgresql?
  • From: Vivek Khera
• Re: How to choose a disc array for Postgresql?
  • From: Luke Lonergan
• Re: How to choose a disc array for Postgresql?
  • From: Joshua D. Drake
• How to choose a disc array for Postgresql?
  • From: Steve Poe
• Re: How to allocate 8 disks
  • From: Greg Smith
• Re: 12 disks raid setup
  • From: Greg Smith
• Re: How to allocate 8 disks
  • From: Scott Marlowe
• Re: How to allocate 8 disks
  • From: Craig James
• Re: How to allocate 8 disks
  • From: Joshua D. Drake
• Re: How to allocate 8 disks
  • From: Scott Marlowe
• Re: multi-threaded pgloader needs your tests
  • From: Simon Riggs
• How to allocate 8 disks
  • From: Craig James
• Re: 12 disks raid setup
  • From: Tom Lane
• Re: 12 disks raid setup
  • From: Scott Marlowe
• Re: 12 disks raid setup
  • From: Franck Routier
• Re: 12 disks raid setup
  • From: Greg Smith
• Re: t1.col like '%t2.col%'
  • From: Tom Lane
• Re: t1.col like '%t2.col%'
  • From: Joshua D. Drake
• Re: 12 disks raid setup
  • From: Shane Ambler
• Re: t1.col like '%t2.col%'
  • From: Gregory Williamson
• Re: t1.col like '%t2.col%'
  • From: Joshua D. Drake
• Re: t1.col like '%t2.col%'
  • From: Dan Kaplan
• Re: 12 disks raid setup
  • From: Mark Kirkwood
• Re: 12 disks raid setup
  • From: Vivek Khera
• Re: 12 disks raid setup
  • From: Matthew
• Re: 12 disks raid setup
  • From: Joshua D. Drake
• Re: 12 disks raid setup
  • From: Jignesh K. Shah
• Re: 12 disks raid setup
  • From: Greg Smith
• Re: 12 disks raid setup
  • From: Franck Routier
• Re: 12 disks raid setup
  • From: Scott Marlowe
• 12 disks raid setup
  • From: Franck Routier
• Re: Bypassing useless ORDER BY in a VIEW
  • From: Robins Tharakan
• Re: Bypassing useless ORDER BY in a VIEW
  • From: Tom Lane
• Re: Bypassing useless ORDER BY in a VIEW
  • From: Dean Gibson (DB Administrator)
• Re: PG planning randomly ?
  • From: Laurent Raufaste
• Re: Bypassing useless ORDER BY in a VIEW
  • From: Tom Lane
• Bypassing useless ORDER BY in a VIEW
  • From: Robins Tharakan
• Re: t1.col like '%t2.col%'
  • From: Oleg Bartunov
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: when is a DELETE FK trigger planned?
  • From: Andrew Lazarus
• Re: disabling an index without deleting it?
  • From: Tom Lane
• Re: disabling an index without deleting it?
  • From: Tom Lane
• Re: disabling an index without deleting it?
  • From: Kevin Grittner
• Re: disabling an index without deleting it?
  • From: Tom Lane
• Re: disabling an index without deleting it?
  • From: Kevin Grittner
• Re: PG planning randomly ?
  • From: Tom Lane
• Re: Optimizing t1.col like '%t2.col%'
  • From: Tom Lane
• Re: disabling an index without deleting it?
  • From: Tom Lane
• Optimizing t1.col like '%t2.col%'
  • From: Dan Kaplan
• t1.col like '%t2.col%'
  • From: Dan Kaplan
• Re: questions about CLUSTER
  • From: Bill Moran
• Re: disabling an index without deleting it?
  • From: Jeff Davis
• Re: questions about CLUSTER
  • From: Douglas J Hunley
• Re: questions about CLUSTER
  • From: Douglas J Hunley
• Re: questions about CLUSTER
  • From: Bill Moran
• Re: PG planning randomly ?
  • From: Laurent Raufaste
• Re: how to identify expensive steps in an explain analyze output
  • From: Frits Hoogland
• questions about CLUSTER
  • From: Douglas J Hunley
• Re: how to identify expensive steps in an explain analyze output
  • From: Tom Lane
• how to identify expensive steps in an explain analyze output
  • From: Frits Hoogland
• how to identify expensive steps in an explain analyze output
  • From: Frits Hoogland
• Re: disabling an index without deleting it?
  • From: Markus Bertheau
• Re: LISTEN / NOTIFY performance in 8.3
  • From: James Mansion
• Re: disabling an index without deleting it?
  • From: Tom Lane
• Re: disabling an index without deleting it?
  • From: Scott Marlowe
• Re: disabling an index without deleting it?
  • From: Tom Lane
• Re: disabling an index without deleting it?
  • From: Scott Marlowe
• Re: disabling an index without deleting it?
  • From: Markus Bertheau
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: James Mansion
• Re: disabling an index without deleting it?
  • From: Joshua D. Drake
• Re: disabling an index without deleting it?
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: PG planning randomly ?
  • From: Tom Lane
• Re: PG planning randomly ?
  • From: Tom Lane
• Re: disabling an index without deleting it?
  • From: Joshua D. Drake
• Re: disabling an index without deleting it?
  • From: Scott Marlowe
• disabling an index without deleting it?
  • From: Peter Koczan
• Re: PG planning randomly ?
  • From: Scott Marlowe
• Re: PG planning randomly ?
  • From: Laurent Raufaste
• Re: PG planning randomly ?
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• Re: PG planning randomly ?
  • From: Laurent Raufaste
• Re: Q on views and performance
  • From: Kynn Jones
• Re: PG planning randomly ?
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: PG planning randomly ?
  • From: Laurent Raufaste
• PG planning randomly ?
  • From: Laurent Raufaste
• Re: response time when querying via JDBC and via psql differs
  • From: valgog
• multi-threaded pgloader needs your tests
  • From: Dimitri Fontaine
• Re: when is a DELETE FK trigger planned?
  • From: Tom Lane
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Stephen Denne
• Re: Weird issue with planner choosing seq scan
  • From: Stephen Denne
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Stephen Denne
• when is a DELETE FK trigger planned?
  • From: Andrew Lazarus
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: Q on views and performance
  • From: Matthew
• Re: Q on views and performance
  • From: Kynn Jones
• Re: Weird issue with planner choosing seq scan
  • From: Matthew
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: response time when querying via JDBC and via psql differs
  • From: Nikolas Everett
• Re: Q on views and performance
  • From: Matthew
• Re: Q on views and performance
  • From: Matthew
• Re: CORRECTION to msg 'loading same instance of dump to two different servers simultaneously'
  • From: Matthew
• Re: response time when querying via JDBC and via psql differs
  • From: Markus Bertheau
• response time when querying via JDBC and via psql differs
  • From: Pavel Rotek
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: Weird issue with planner choosing seq scan
  • From: Scott Marlowe
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Scott Marlowe
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Stephen Denne
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Tom Lane
• Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: Q on views and performance
  • From: Dean Gibson (DB Administrator)
• Re: Q on views and performance
  • From: Dean Gibson (DB Administrator)
• Re: Q on views and performance
  • From: Kynn Jones
• Re: Q on views and performance
  • From: Dean Gibson (DB Administrator)
• Re: Q on views and performance
  • From: Dean Gibson (DB Administrator)
• Re: Q on views and performance
  • From: Robins Tharakan
• Re: Q on views and performance
  • From: Kynn Jones
• Re: Q on views and performance
  • From: Kynn Jones
• Re: store A LOT of 3-tuples for comparisons
  • From: Moritz Onken
• Re: store A LOT of 3-tuples for comparisons
  • From: Shane Ambler
• Re: Q on views and performance
  • From: Dean Gibson (DB Administrator)
• Q on views and performance
  • From: Kynn Jones
• loading same instance of dump to two different servers simultaneously?
  • From: Susan Russo
• CORRECTION to msg 'loading same instance of dump to two different servers simultaneously'
  • From: Susan Russo
• Re: store A LOT of 3-tuples for comparisons
  • From: Matthew
• store A LOT of 3-tuples for comparisons
  • From: Moritz Onken
• Re: 7 hrs for a pg_restore?
  • From: Guillaume Cottenceau
• Re: 4s query want to run faster
  • From: Mark Kirkwood
• config settings, was: 4s query want to run faster
  • From: Scott Marlowe
• Re: 4s query want to run faster
  • From: Dave Cramer
• Re: 4s query want to run faster
  • From: Scott Marlowe
• Re: 4s query want to run faster
  • From: Mark Kirkwood
• Re: 4s query want to run faster
  • From: Scott Marlowe
• Re: 4s query want to run faster
  • From: Adonias Malosso
• Re: 4s query want to run faster
  • From: Claus Guttesen
• Re: 4s query want to run faster
  • From: Adonias Malosso
• Re: 4s query want to run faster
  • From: Claus Guttesen
• Re: 4s query want to run faster
  • From: Adonias Malosso
• Re: 4s query want to run faster
  • From: Scott Marlowe
• 4s query want to run faster
  • From: Adonias Malosso
• Re: 7 hrs for a pg_restore?
  • From: Vivek Khera
• Re: 7 hrs for a pg_restore?
  • From: Tom Lane
• Re: 7 hrs for a pg_restore?
  • From: Guillaume Cottenceau
• Re: 7 hrs for a pg_restore?
  • From: Matthew
• Re: Question about shared_buffers and cpu usage
  • From: Dave Cramer
• Re: planner favors seq scan too early
  • From: Richard Huxton
• Re: Question about shared_buffers and cpu usage
  • From: Scott Marlowe
• planner favors seq scan too early
  • From: Markus Bertheau
• Re: 7 hrs for a pg_restore?
  • From: Chris
• Re: 7 hrs for a pg_restore?
  • From: Gregory Stark
• Question about shared_buffers and cpu usage
  • From: bh yuan
• Re: 7 hrs for a pg_restore?
  • From: Chris
• Re: 7 hrs for a pg_restore?
  • From: Gregory Stark
• Re: 7 hrs for a pg_restore?
  • From: Tom Lane
• Re: 7 hrs for a pg_restore?
  • From: Jeff Davis
• Re: 7 hrs for a pg_restore?
  • From: Matthew
• Re: 7 hrs for a pg_restore?
  • From: Jeff Davis
• Re: 7 hrs for a pg_restore?
  • From: Erik Jones
• Re: 7 hrs for a pg_restore?
  • From: Matthew
• Re: 7 hrs for a pg_restore?
  • From: Tom Lane
• Re: 7 hrs for a pg_restore?
  • From: Erik Jones
• Re: Anyone using a SAN?
  • From: Michael Stone
• Re: Anyone using a SAN?
  • From: Michael Stone
• Re: 7 hrs for a pg_restore?
  • From: Gregory Stark
• Re: Anyone using a SAN?
  • From: C.
• Re: Anyone using a SAN?
  • From: Matthew
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: Need Help selecting Large Data From PQSQL
  • From: Richard Huxton
• Re: 7 hrs for a pg_restore?
  • From: ohp
• Re: mis-estimate in nested query causes slow runtimes
  • From: Chris Kratz
• Need Help selecting Large Data From PQSQL
  • From: shilpa.raghavendra
• Re: 7 hrs for a pg_restore?
  • From: Pavan Deolasee
• Re: Anyone using a SAN?
  • From: Sven Geisler
• Re: Fwd: wal_sync_methods for AIX
  • From: Greg Smith
• Re: 7 hrs for a pg_restore?
  • From: Greg Smith
• Re: wal_sync_methods for AIX
  • From: Erik Jones
• Re: wal_sync_methods for AIX
  • From: Dan Langille
• Re: 7 hrs for a pg_restore?
  • From: Erik Jones
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: Fwd: wal_sync_methods for AIX
  • From: JP Fletcher
• Re: 7 hrs for a pg_restore?
  • From: Dave Cramer
• Re: 7 hrs for a pg_restore?
  • From: Jeff
• Re: 7 hrs for a pg_restore?
  • From: Jeff Davis
• Re: 7 hrs for a pg_restore?
  • From: Jeff Davis
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Dave Cramer
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Jeff Davis
• Re: 7 hrs for a pg_restore?
  • From: Tom Lane
• Re: 7 hrs for a pg_restore?
  • From: Dave Cramer
• Re: 7 hrs for a pg_restore?
  • From: Richard Huxton
• Re: 7 hrs for a pg_restore?
  • From: Joshua D. Drake
• 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: Disable WAL completely
  • From: Andrew Sullivan
• strange plan choice
  • From: Cousin Marc
• Re: Disable WAL completely
  • From: Matthew
• Re: Anyone using a SAN?
  • From: Peter Koczan
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Greg Smith
• Re: mis-estimate in nested query causes slow runtimes
  • From: Chris Kratz
• Re: Disable WAL completely
  • From: Tobias Brox
• Re: Controling where temporary files are created
  • From: Albert Cervera Areny
• Re: Disable WAL completely
  • From: Erik Jones
• Controling where temporary files are created
  • From: Nikolas Everett
• Re: Disable WAL completely
  • From: hubert depesz lubaczewski
• Re: Disable WAL completely
  • From: Kathirvel, Jeevanandam
• Re: Disable WAL completely
  • From: A. Kretschmer
• Re: Disable WAL completely
  • From: hubert depesz lubaczewski
• Disable WAL completely
  • From: Kathirvel, Jeevanandam
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Peter Schuller
• Re: Example web access to Postgres DB
  • From: Adam Tauno Williams
• Re: Example web access to Postgres DB
  • From: Dave Cramer
• Re: Example web access to Postgres DB
  • From: Bill Moran
• Re: Example web access to Postgres DB
  • From: Tino Wildenhain
• Example web access to Postgres DB
  • From: Mohamed Ali JBELI
• Re: Anyone using a SAN?
  • From: Greg Smith
• Re: wal_sync_methods for AIX
  • From: Erik Jones
• Re: wal_sync_methods for AIX
  • From: Joshua D. Drake
• wal_sync_methods for AIX
  • From: Dan Langille
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Erik Jones
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Jignesh K. Shah
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Joshua D. Drake
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Erik Jones
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Josh Berkus
• Re: Query slows after offset of 100K
  • From: Matthew
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Greg Smith
• Re: Creating and updating table using function parameter reference
  • From: Linux Guru
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Peter Schuller
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Kenneth Marshall
• shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Peter Schuller
• Re: Avoid long-running transactions in a long-runningstored procedure?
  • From: David Crane
• Re: Avoid long-running transactions in a long-running stored procedure?
  • From: Ow Mun Heng
• Re: Avoid long-running transactions in a long-running stored procedure?
  • From: Josh Berkus
• Avoid long-running transactions in a long-running stored procedure?
  • From: David Crane
• Re: Query slows after offset of 100K
  • From: Tom Lane
• Re: Query slows after offset of 100K
  • From: Greg Smith
• Re: Join Query Perfomance Issue
  • From: Chris
• Re: Query slows after offset of 100K
  • From: Tom Lane
• Re: Query slows after offset of 100K
  • From: Mark Lewis
• Re: Query slows after offset of 100K
  • From: Michael Lorenz
• Re: Query slows after offset of 100K
  • From: Tom Lane
• Query slows after offset of 100K
  • From: Michael Lorenz
• Re: Creating and updating table using function parameter reference
  • From: Albert Cervera Areny
• Re: Creating and updating table using function parameter reference
  • From: Linux Guru
• Re: Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Anyone using a SAN?
  • From: Greg Stark
• Re: Anyone using a SAN?
  • From: Peter Koczan
• Re: Anyone using a SAN?
  • From: Bruce Momjian
• Re: Anyone using a SAN?
  • From: Scott Marlowe
• Re: Anyone using a SAN?
  • From: Tobias Brox
• Re: Anyone using a SAN?
  • From: Greg Smith
• Re: HOT TOAST?
  • From: Josh Berkus
• Re: Anyone using a SAN?
  • From: Arjen van der Meijden
• Re: Join Query Perfomance Issue
  • From: Scott Marlowe
• Re: Anyone using a SAN?
  • From: Tobias Brox
• Re: Optimizing No matching record Queries
  • From: Gregory Stark
• Re: Dell Perc/6
  • From: Tore Halset
• Re: Optimizing No matching record Queries
  • From: Pallav Kalva
• Re: Dell Perc/6
  • From: Tore Halset
• Re: HOT TOAST?
  • From: Tom Lane
• Re: Anyone using a SAN?
  • From: Alex Deucher
• HOT TOAST?
  • From: Josh Berkus
• Re: Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Anyone using a SAN?
  • From: Kenneth Marshall
• Re: Small DB Server Advice
  • From: Greg Smith
• Anyone using a SAN?
  • From: Peter Koczan
• Re: Dell Perc/6
  • From: Merlin Moncure
• Re: Join Query Perfomance Issue
  • From: Tom Lane
• Re: Creating and updating table using function parameter reference
  • From: Albert Cervera Areny
• Re: Small DB Server Advice
  • From: Matthew
• Re: Small DB Server Advice
  • From: Magnus Hagander
• Creating and updating table using function parameter reference
  • From: Linux Guru
• Re: Small DB Server Advice
  • From: Matthew
• Small DB Server Advice
  • From: Rory Campbell-Lange
• Re: Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Dell Perc/6
  • From: Dave Cramer
• Re: Update with Subquery Performance
  • From: Linux Guru
• Re: Dell Perc/6
  • From: Tore Halset
• Re: Optimizing No matching record Queries
  • From: Richard Huxton
• Re: Optimizing No matching record Queries
  • From: Gregory Stark
• Re: Optimizing No matching record Queries
  • From: Dean Gibson (DB Administrator)
• Re: Optimizing No matching record Queries
  • From: Stephen Denne
• Optimizing No matching record Queries
  • From: Pallav Kalva
• Re: Join Query Perfomance Issue
  • From: Peter Koczan
• Re: Dell Perc/6
  • From: Greg Smith
• Re: Questions about enabling SSL
  • From: fabrix peñuelas
• Dell Perc/6
  • From: Craig James
• Re: Update with Subquery Performance
  • From: Tom Lane
• Re: mis-estimate in nested query causes slow runtimes
  • From: Chris Kratz
• Re: mis-estimate in nested query causes slow runtimes
  • From: Chris Kratz
• Re: Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Update with Subquery Performance
  • From: Linux Guru
• Re: Update with Subquery Performance
  • From: Linux Guru
• Re: Question about CLUSTER
  • From: Michael Fuhr
• Re: Questions about enabling SSL
  • From: Michael Fuhr
• Re: Questions about enabling SSL
  • From: Michael Fuhr
• Questions about enabling SSL
  • From: fabrix peñuelas
• Re: mis-estimate in nested query causes slow runtimes
  • From: Tom Lane
• mis-estimate in nested query causes slow runtimes
  • From: Chris Kratz
• Re: Join Query Perfomance Issue
  • From: Scott Marlowe
• Re: Join Query Perfomance Issue
  • From: Scott Marlowe
• Re: Question about CLUSTER
  • From: Scott Marlowe
• Re: Update with Subquery Performance
  • From: Scott Marlowe
• Question about CLUSTER
  • From: salman
• Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Update with Subquery Performance
  • From: Tom Lane
• Re: Optimizer : query rewrite and execution plan ?
  • From: Tom Lane
• Update with Subquery Performance
  • From: Linux Guru
• Re: Optimizer : query rewrite and execution plan ?
  • From: Simon Riggs
• Re: Parallel inserts
  • From: Bruce Momjian
• Parallel inserts
  • From: Ivan Voras
• Re: Benchmark Data requested
  • From: Mark Wong
• Re: Benchmark Data requested
  • From: Mark Wong
• Wrong number of rows estimation by the planner
  • From: Yonatan Ben-Nes
• Re: index usage on arrays
  • From: Tom Lane
• Re: index usage on arrays
  • From: Oleg Bartunov
• index usage on arrays
  • From: andrew klassen
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Mark Lewis
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Kenneth Marshall
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Matthew
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Greg Smith
• Index Scan Backward + check additional condition before heap access
  • From: Markus Bertheau
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Greg Smith
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Luke Lonergan
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Benchmark Data requested
  • From: Dimitri Fontaine
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Jignesh K. Shah
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Luke Lonergan
• Re: Optimizer : query rewrite and execution plan ?
  • From: Tom Lane
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Greg Smith
• Re: Benchmark Data requested
  • From: Greg Smith
• Re: Optimizer : query rewrite and execution plan ?
  • From: Roberts, Jon
• Re: Optimizer : query rewrite and execution plan ?
  • From: Erik Jones
• Re: Optimizer : query rewrite and execution plan ?
  • From: Roberts, Jon
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Optimizer : query rewrite and execution plan ?
  • From: Theo Kramer
• Re: Optimizer : query rewrite and execution plan ?
  • From: Simon Riggs
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Simon Riggs
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Benchmark Data requested
  • From: Dimitri Fontaine
• Re: Optimizer : query rewrite and execution plan ?
  • From: Richard Huxton
• Re: Optimizer : query rewrite and execution plan ?
  • From: SURANTYN Jean François
• Re: Optimizer : query rewrite and execution plan ?
  • From: Richard Huxton
• Optimizer : query rewrite and execution plan ?
  • From: SURANTYN Jean François
• Re: Benchmark Data requested
  • From: NikhilS
• Re: Benchmark Data requested
  • From: Greg Smith
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Benchmark Data requested
  • From: Heikki Linnakangas