Postgres Performance Date Index

• Thread Index

• Re: Pros and Cons of 8.3.1
  • From: Kevin Grittner
• Re: Pros and Cons of 8.3.1
  • From: Kevin Grittner
• Re: Pros and Cons of 8.3.1
  • From: Kevin Grittner
• Re: Pros and Cons of 8.3.1
  • From: Joshua D. Drake
• Re: Pros and Cons of 8.3.1
  • From: Justin
• Re: Please ignore ...
  • From: Alvaro Herrera
• Re: Vacuum statistics
  • From: chirag . dave
• Re: Pros and Cons of 8.3.1
  • From: Claus Guttesen
• Pros and Cons of 8.3.1
  • From: Gauri Kanekar
• Re: Benchmarks WAS: Sun Talks about MySQL
  • From: Jignesh K. Shah
• Re: Please ignore ...
  • From: D'Arcy J.M. Cain
• Re: Postgres replication
  • From: Fujii Masao
• Re: Please ignore ...
  • From: Tino Wildenhain
• Re: Please ignore ...
  • From: Greg Smith
• Re: Please ignore ...
  • From: Justin
• Re: Please ignore ...
  • From: D'Arcy J.M. Cain
• Re: Understanding histograms
  • From: Tom Lane
• Please ignore ...
  • From: Marc G. Fournier
• Re: Max shared_buffers
  • From: Craig Ringer
• Re: Max shared_buffers
  • From: Scott Marlowe
• [Fwd: Re: Max shared_buffers]
  • From: Justin
• Re: Max shared_buffers
  • From: Matthew
• Re: Max shared_buffers
  • From: Andrej Ricnik-Bay
• Re: Max shared_buffers
  • From: Scott Marlowe
• Re: Performance Implications of Using Exceptions
  • From: Robins Tharakan
• Re: Max shared_buffers
  • From: sathiya psql
• Re: Performance Implications of Using Exceptions
  • From: chemuduguntar@xxxxxxxxx
• Re: POSIX file updates
  • From: James Mansion
• Max shared_buffers
  • From: bitaoxiao
• Re: SSDs
  • From: Merlin Moncure
• Re: POSIX file updates
  • From: Greg Smith
• Re: POSIX file updates
  • From: Greg Smith
• Re: POSIX file updates
  • From: James Mansion
• Re: POSIX file updates
  • From: Andreas Kostyrka
• Re: Performance Implications of Using Exceptions
  • From: James Mansion
• Re: POSIX file updates
  • From: James Mansion
• Re: Cursors and different settings for default_statistics_target
  • From: Hell, Robert
• Re: SSDs
  • From: Arjen van der Meijden
• SSDs
  • From: James Mansion
• Re: Cursors and different settings for default_statistics_target
  • From: Tom Lane
• Re: Cursors and different settings for default_statistics_target
  • From: Hell, Robert
• Too many commands in a transaction
  • From: samantha mahindrakar
• Re: Cursors and different settings for default_statistics_target
  • From: Steinar H. Gunderson
• Re: Cursors and different settings for default_statistics_target
  • From: Tom Lane
• Re: Cursors and different settings for default_statistics_target
  • From: Hell, Robert
• Re: Cursors and different settings for default_statistics_target
  • From: Tom Lane
• Re: Cursors and different settings for default_statistics_target
  • From: Hell, Robert
• Insert time
  • From: Ioana Danes
• Re: Cursors and different settings for default_statistics_target
  • From: Tom Lane
• Re: check performance parameters
  • From: Matthew
• Cursors and different settings for default_statistics_target
  • From: Hell, Robert
• check performance parameters
  • From: Sabin Coanda
• Re: Bad prepare performance
  • From: Cédric Villemain
• Re: POSIX file updates
  • From: Tom Lane
• Re: Performance Implications of Using Exceptions
  • From: Tom Lane
• Re: Performance Implications of Using Exceptions
  • From: Robins Tharakan
• Re: Performance Implications of Using Exceptions
  • From: Ravi Chemudugunta
• Re: Performance Implications of Using Exceptions
  • From: Stephen Denne
• Re: Performance Implications of Using Exceptions
  • From: Stephen Frost
• Performance Implications of Using Exceptions
  • From: Ravi Chemudugunta
• Re: POSIX file updates
  • From: Greg Smith
• Re: POSIX file updates
  • From: James Mansion
• Re: POSIX file updates
  • From: James Mansion
• Re: POSIX file updates
  • From: James Mansion
• Re: POSIX file updates
  • From: Mark Mielke
• POSIX file updates
  • From: James Mansion
• optimizing query performance
  • From: Frits Hoogland
• Re: Bad prepare performance
  • From: Cédric Villemain
• Bad prepare performance
  • From: Martin Kjeldsen
• Re: Planning a new server - help needed
  • From: Guy Rouillier
• Re: Planning a new server - help needed
  • From: Craig Ringer
• Re: Planning a new server - help needed
  • From: Greg Smith
• Re: Planning a new server - help needed
  • From: Peter Eisentraut
• Re: Planning a new server - help needed
  • From: James Mansion
• Re: Planning a new server - help needed
  • From: PFC
• Re: Planning a new server - help needed
  • From: James Mansion
• Re: Planning a new server - help needed
  • From: Weinzierl Stefan
• Re: Planning a new server - help needed
  • From: Dan Harris
• Re: Planning a new server - help needed
  • From: Greg Smith
• Re: using like in a prepare doesnt' use the right index
  • From: Gavin Sherry
• Re: Planning a new server - help needed
  • From: Laszlo Nagy
• Re: Planning a new server - help needed
  • From: Reko Turja
• Re: Planning a new server - help needed
  • From: Claus Guttesen
• Planning a new server - help needed
  • From: Laszlo Nagy
• Re: vacuum in Postgresql 8.0.x slowing down the database
  • From: Vinubalaji Gopal
• using like in a prepare doesnt' use the right index
  • From: Dave Cramer
• Re: "Slow" query or just "Bad hardware"?
  • From: Alvaro Herrera
• Re: "Slow" query or just "Bad hardware"?
  • From: Luke Lonergan
• Re: postgresql is slow with larger table even it is in RAM
  • From: Luke Lonergan
• Re: "Slow" query or just "Bad hardware"?
  • From: Bill Moran
• Re: "Slow" query or just "Bad hardware"?
  • From: PFC
• Re: "Slow" query or just "Bad hardware"?
  • From: PFC
• Re: "Slow" query or just "Bad hardware"?
  • From: Matthew
• "Slow" query or just "Bad hardware"?
  • From: Jesper Krogh
• Re: how can a couple of expensive queries drag my system down?
  • From: Erik Jones
• Re: how can a couple of expensive queries drag my system down?
  • From: Scott Marlowe
• Re: how can a couple of expensive queries drag my system down?
  • From: Shane Ambler
• Re: postgresql is slow with larger table even it is in RAM
  • From: Peter Koczan
• Re: how can a couple of expensive queries drag my system down?
  • From: PFC
• Re: how can a couple of expensive queries drag my system down?
  • From: Scott Marlowe
• Re: how can a couple of expensive queries drag my system down?
  • From: Alan Hodgson
• Re: vacuum in Postgresql 8.0.x slowing down the database
  • From: Joshua D. Drake
• vacuum in Postgresql 8.0.x slowing down the database
  • From: Vinubalaji Gopal
• how can a couple of expensive queries drag my system down?
  • From: p prince
• Query Optimization
  • From: Gopinath Narasimhan
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: PFC
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: Craig Ringer
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: A. Kretschmer
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: Marinos Yannikos
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: Matthew
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: A. Kretschmer
• 1-/2-dimensional indexes for common columns, rationale?
  • From: Marinos Yannikos
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Matthew
• Preparing statements on connection startup
  • From: PFC
• Re: postgresql is slow with larger table even it is in RAM
  • From: Chris Browne
• Re: postgresql is slow with larger table even it is in RAM
  • From: sathiya psql
• Re: postgresql is slow with larger table even it is in RAM
  • From: Luke Lonergan
• Re: postgresql is slow with larger table even it is in RAM
  • From: Bill Moran
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Bill Moran
• Re: PostgreSQL NetApp and NFS
  • From: Jurgen Haan
• Re: postgresql is slow with larger table even it is in RAM
  • From: sathiya psql
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Ivan Voras
• Re: postgresql is slow with larger table even it is in RAM
  • From: Bill Moran
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Craig Ringer
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: sathiya psql
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Craig Ringer
• Re: increasing shared buffer slow downs query performance.
  • From: Pavan Deolasee
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: sathiya psql
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Alvaro Herrera
• Re: postgresql is slow with larger table even it is in RAM
  • From: Alvaro Herrera
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: sathiya psql
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Harald Armin Massa
• what is the maximum number of rows in a table in postgresql 8.1
  • From: sathiya psql
• Re: postgresql is slow with larger table even it is in RAM
  • From: Craig Ringer
• Re: postgresql is slow with larger table even it is in RAM
  • From: hubert depesz lubaczewski
• Re: postgresql is slow with larger table even it is in RAM
  • From: sathiya psql
• postgresql is slow with larger table even it is in RAM
  • From: sathiya psql
• Re: Planning hot/live backups?
  • From: Matthew T. O'Connor
• Re: slow pg_connect()
  • From: Chris
• Re: waiting for harddisk
  • From: Scott Marlowe
• Re: Planning hot/live backups?
  • From: Miguel Arroz
• Re: Planning hot/live backups?
  • From: Steve Poe
• Re: Planning hot/live backups?
  • From: Matthew T. O'Connor
• Re: Planning hot/live backups?
  • From: Tom Lane
• Re: Planning hot/live backups?
  • From: paul rivers
• Re: Planning hot/live backups?
  • From: Matthew T. O'Connor
• Re: Planning hot/live backups?
  • From: Campbell, Lance
• Planning hot/live backups?
  • From: Steve Poe
• Re: Turn correlated in subquery into join
  • From: Tom Lane
• Re: waiting for harddisk
  • From: PFC
• waiting for harddisk
  • From: petchimuthu lingam
• Re: slow pg_connect()
  • From: Thomas Pundt
• Re: slow pg_connect()
  • From: Tommy Gildseth
• Re: increasing shared buffer slow downs query performance.
  • From: Andreas Kretschmer
• increasing shared buffer slow downs query performance.
  • From: petchimuthu lingam
• Re: slow pg_connect()
  • From: vincent
• Re: slow pg_connect()
  • From: Craig Ringer
• Re: slow pg_connect()
  • From: Craig Ringer
• Turn correlated in subquery into join
  • From: Dennis Bjorklund
• slow pg_connect()
  • From: firerox
• Re: Views and functions returning sets of records
  • From: Tom Lane
• Re: Views and functions returning sets of records
  • From: Giorgio Valoti
• Re: Views and functions returning sets of records
  • From: Andreas Kretschmer
• Re: Views and functions returning sets of records
  • From: Tom Lane
• Re: Views and functions returning sets of records
  • From: Andreas Kretschmer
• Views and functions returning sets of records
  • From: Giorgio Valoti
• Re: Having MANY MANY empty columns in database
  • From: sathiya psql
• Re: Having MANY MANY empty columns in database
  • From: Craig Ringer
• Having MANY MANY empty columns in database
  • From: sathiya psql
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Bruce Momjian
• Re: PostgreSQL NetApp and NFS
  • From: Bruce Momjian
• Re: PG writes a lot to the disk
  • From: Bill Moran
• Re: PG writes a lot to the disk
  • From: Laurent Raufaste
• Re: PG writes a lot to the disk
  • From: Gregory Stark
• Re: PostgreSQL NetApp and NFS
  • From: Gregory Stark
• Re: PG writes a lot to the disk
  • From: Laurent Raufaste
• Re: PostgreSQL NetApp and NFS
  • From: Dawid Kuroczko
• Re: PostgreSQL NetApp and NFS
  • From: Tom Lane
• Re: PostgreSQL NetApp and NFS
  • From: Bruce Momjian
• Re: PostgreSQL NetApp and NFS
  • From: Woody Woodring
• Re: PostgreSQL NetApp and NFS
  • From: Tom Lane
• Re: PostgreSQL NetApp and NFS
  • From: Frits Hoogland
• Re: PostgreSQL NetApp and NFS
  • From: Bruce Momjian
• Re: PG writes a lot to the disk
  • From: Kris Jurka
• PostgreSQL NetApp and NFS
  • From: Chris Hoover
• Re: PG writes a lot to the disk
  • From: Tom Lane
• Re: PG writes a lot to the disk
  • From: Bill Moran
• Re: PG writes a lot to the disk
  • From: Albe Laurenz
• Re: PG writes a lot to the disk
  • From: Laurent Raufaste
• Re: Anyone using a SAN?
  • From: Peter Koczan
• Windows XP 64 bit
  • From: Campbell, Lance
• Re: PG writes a lot to the disk
  • From: Albe Laurenz
• Re: PG writes a lot to the disk
  • From: Greg Smith
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Bill Moran
• Re: PG writes a lot to the disk
  • From: Bill Moran
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Mark Steben
• Re: What is the best way to storage music files in Postgresql
  • From: Gregory Youngblood
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Alvaro Herrera
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Bill Moran
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Mark Steben
• PG writes a lot to the disk
  • From: Laurent Raufaste
• Re: What is the best way to storage music files in Postgresql
  • From: Gregory Youngblood
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Chris
• Re: TB-sized databases
  • From: Ron Mayer
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: What is the best way to storage music files in Postgresql
  • From: Gregory Stark
• Re: Planner mis-estimation using nested loops followup
  • From: KC ESL
• Re: What is the best way to storage music files in Postgresql
  • From: david
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: Planner mis-estimation using nested loops followup
  • From: Stephen Denne
• question on TRUNCATE vs VACUUM FULL
  • From: Mark Steben
• Re: What is the best way to storage music files in Postgresql
  • From: Gregory Stark
• Re: What is the best way to storage music files in Postgresql
  • From: david
• Re: Planner mis-estimation using nested loops followup
  • From: Scott Marlowe
• Re: What is the best way to storage music files in Postgresql
  • From: david
• Re: What is the best way to storage music files in Postgresql
  • From: Andrej Ricnik-Bay
• Re: TB-sized databases
  • From: Ron Mayer
• Re: Planner mis-estimation using nested loops followup
  • From: Matthew
• Re: Planner mis-estimation using nested loops followup
  • From: Chris Kratz
• Re: Planner mis-estimation using nested loops followup
  • From: Joshua D. Drake
• Planner mis-estimation using nested loops followup
  • From: Chris Kratz
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Michael Stone
• Re: TB-sized databases
  • From: Tom Lane
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: What is the best way to storage music files in Postgresql
  • From: Andrej Ricnik-Bay
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: James Mansion
• Re: TB-sized databases
  • From: Ron Mayer
• Re: What is the best way to storage music files in Postgresql
  • From: Peter Koczan
• Re: performance tools
  • From: Franck Routier
• Re: TB-sized databases
  • From: Pablo Alcaraz
• Re: TB-sized databases
  • From: Bruce Momjian
• Re: TB-sized databases
  • From: Tom Lane
• Re: TB-sized databases
  • From: Bruce Momjian
• Re: performance tools
  • From: Andrej Ricnik-Bay
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Scott Marlowe
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Enrico Sirola
• Re: What is the best way to storage music files in Postgresql
  • From: Rich
• Re: What is the best way to storage music files in Postgresql
  • From: Rich
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Craig James
• Re: What is the best way to storage music files in Postgresql
  • From: Peter Koczan
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Dave Cramer
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: performance tools
  • From: Ben Chobot
• Re: performance tools
  • From: sathiya psql
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: performance tools
  • From: Mark Steben
• performance tools
  • From: sathiya psql
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Tino Wildenhain
• Re: Lots of "semop" calls under load
  • From: Albe Laurenz
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Craig Ringer
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Andrej Ricnik-Bay
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Scott Marlowe
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Dave Cramer
• 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: best way to run maintenance script
  • From: Peter Eisentraut
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Dave Cramer
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: What is the best way to storage music files in Postgresql
  • From: Craig James
• What is the best way to storage music files in Postgresql
  • From: Rich
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: best way to run maintenance script
  • From: Gregory Stark
• Re: best way to run maintenance script
  • From: Vinubalaji Gopal
• Re: best way to run maintenance script
  • From: Vinubalaji Gopal
• Re: best way to run maintenance script
  • From: Joshua D. Drake
• Re: best way to run maintenance script
  • From: Tom Lane
• Re: best way to run maintenance script
  • From: Vinubalaji Gopal
• Re: best way to run maintenance script
  • From: Joshua D. Drake
• best way to run maintenance script
  • From: Vinubalaji Gopal
• Re: Adaptec 5805 SAS Raid
  • From: Leigh Dyer
• Re: Anyone using a SAN?
  • From: Peter Koczan
• Re: The "many nulls" problem
  • From: Oleg Bartunov
• Re: The "many nulls" problem
  • From: Kynn Jones
• Re: The "many nulls" problem
  • From: Kynn Jones
• Re: The "many nulls" problem
  • From: Heikki Linnakangas
• Re: Hardware question for a DB server
  • From: Scott Marlowe
• Re: Hardware question for a DB server
  • From: Pascal Cohen
• Re: The "many nulls" problem
  • From: Oleg Bartunov
• The "many nulls" problem
  • From: Kynn Jones
• Adaptec 5805 SAS Raid
  • From: Glyn Astill
• Re: Lots of "semop" calls under load
  • From: Tom Lane
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Michael Stone
• 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