Postgres Performance Date Index

• Thread Index

• Re: shared_buffers advice
  • From: Greg Smith
• Re: mysql to postgresql, performance questions
  • From: Stephen Frost
• Re: mysql to postgresql, performance questions
  • From: Grzegorz Jaśkiewicz
• Re: mysql to postgresql, performance questions
  • From: Thom Brown
• Re: mysql to postgresql, performance questions
  • From: Kenneth Marshall
• Re: mysql to postgresql, performance questions
  • From: tv
• mysql to postgresql, performance questions
  • From: Corin
• Re: pg_dump far too slow
  • From: Matthew Wakeling
• Re: shared_buffers advice
  • From: Dimitri Fontaine
• Re: Forcing index scan on query produces 16x faster
  • From: Eger, Patrick
• Re: Testing FusionIO
  • From: Ben Chobot
• Re: Forcing index scan on query produces 16x faster
  • From: Tom Lane
• Re: Forcing index scan on query produces 16x faster
  • From: David Wilson
• Forcing index scan on query produces 16x faster
  • From: Christian Brink
• Re: Building multiple indexes concurrently
  • From: Greg Smith
• Re: Building multiple indexes concurrently
  • From: Alvaro Herrera
• Re: Testing FusionIO
  • From: david
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Testing FusionIO
  • From: Kenny Gorman
• Re: Building multiple indexes concurrently
  • From: Andres Freund
• Re: Testing FusionIO
  • From: Justin Pitts
• Re: Testing FusionIO
  • From: Justin Pitts
• Re: Testing FusionIO
  • From: Justin Pitts
• Re: Building multiple indexes concurrently
  • From: Greg Smith
• Re: Block at a time ...
  • From: Bob Lunney
• Re: Block at a time ...
  • From: Craig James
• Re: Block at a time ...
  • From: Dave Crooke
• Fwd: shared_buffers advice
  • From: VJK
• Re: Building multiple indexes concurrently
  • From: Rob Wultsch
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Building multiple indexes concurrently
  • From: Tom Lane
• Re: Block at a time ...
  • From: Tom Lane
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Testing FusionIO
  • From: Devrim GÜNDÜZ
• Re: Building multiple indexes concurrently
  • From: Greg Smith
• Re: Block at a time ...
  • From: Greg Stark
• Re: GiST index performance
  • From: Yeb Havinga
• Re: Block at a time ...
  • From: Pierre C
• Re: Building multiple indexes concurrently
  • From: Ben Chobot
• Building multiple indexes concurrently
  • From: Rob Wultsch
• Re: Block at a time ...
  • From: Alvaro Herrera
• Block at a time ...
  • From: Dave Crooke
• Re: shared_buffers advice
  • From: Greg Smith
• Re: shared_buffers advice
  • From: Alvaro Herrera
• Re: shared_buffers advice
  • From: Tom Lane
• Re: shared_buffers advice
  • From: Alvaro Herrera
• Re: shared_buffers advice
  • From: Tom Lane
• Re: shared_buffers advice
  • From: Alvaro Herrera
• Re: shared_buffers advice
  • From: Tom Lane
• Re: shared_buffers advice
  • From: Alvaro Herrera
• Re: shared_buffers advice
  • From: Greg Smith
• Re: shared_buffers advice
  • From: Greg Smith
• Re: Postgres DB maintainenance - vacuum and reindex
  • From: Ing. Marcos Ortiz Valmaseda
• Re: Postgres DB maintainenance - vacuum and reindex
  • From: Ben Chobot
• Re: Postgres DB maintainenance - vacuum and reindex
  • From: Scott Marlowe
• Re: GiST index performance
  • From: Yeb Havinga
• Postgres DB maintainenance - vacuum and reindex
  • From: Meena_Ramkumar
• Re: shared_buffers advice
  • From: Greg Stark
• Re: shared_buffers advice
  • From: Greg Stark
• Re: shared_buffers advice
  • From: Tom Lane
• Re: shared_buffers advice
  • From: Pierre C
• Re: shared_buffers advice
  • From: Nikolas Everett
• Re: shared_buffers advice
  • From: Pierre C
• Re: Is DBLINK transactional
  • From: Chris Browne
• Re: shared_buffers advice
  • From: Greg Smith
• Re: shared_buffers advice
  • From: Dave Crooke
• Re: pg_dump far too slow
  • From: Dave Crooke
• Re: GiST index performance
  • From: Robert Haas
• Re: pg_dump far too slow
  • From: Robert Haas
• Re: shared_buffers advice
  • From: Scott Marlowe
• Re: Is DBLINK transactional
  • From: Hannu Krosing
• [offtopic] Problems subscribing to Postgres mailing lists
  • From: Ognjen Blagojevic
• Re: shared_buffers advice
  • From: Paul McGarry
• shared_buffers advice
  • From: Paul McGarry
• Strange workaround for slow query
  • From: Kees van Dieren
• Re: shared_buffers advice
  • From: Scott Carey
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: VJK
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Matthew Wakeling
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: VJK
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Tom Lane
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Tom Lane
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: VJK
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Greg Smith
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Kevin Grittner
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Kevin Grittner
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: VJK
• Re: default_statistics_target
  • From: Greg Smith
• Re: default_statistics_target
  • From: Albe Laurenz
• Updated benchmarking category on the wiki
  • From: Greg Smith
• default_statistics_target
  • From: Carlo Stonebanks
• Re: pg_dump far too slow
  • From: Tom Lane
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: fkater@xxxxxxxxxxxxxx
• pg_dump far too slow
  • From: David Newall
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Dave Crooke
• Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: fkater@xxxxxxxxxxxxxx
• Re: Is DBLINK transactional
  • From: Craig Ringer
• Re: Is DBLINK transactional
  • From: Jeff Davis
• Re: Is DBLINK transactional
  • From: Merlin Moncure
• Is DBLINK transactional
  • From: elias ghanem
• Re: shared_buffers advice
  • From: Greg Smith
• Re: How to SELECT
  • From: Angayarkanni
• Re: How to SELECT
  • From: Dave Crooke
• Re: How to SELECT
  • From: A. Kretschmer
• How to SELECT
  • From: Angayarkanni
• Re: shared_buffers advice
  • From: Ben Chobot
• shared_buffers advice
  • From: Paul McGarry
• Re: Strange workaround for slow query
  • From: Robert Haas
• Re: Strange workaround for slow query
  • From: Tom Lane
• Re: Strange workaround for slow query
  • From: Robert Haas
• Re: Bad query plan inside EXISTS clause
  • From: Benoit Delbosc
• Re: Strange workaround for slow query
  • From: Harald Fuchs
• Re: Bad query plan inside EXISTS clause
  • From: Tom Lane
• Re: Bad query plan inside EXISTS clause
  • From: Benoit Delbosc
• Re: Bad query plan inside EXISTS clause
  • From: Yeb Havinga
• Re: Bad query plan inside EXISTS clause
  • From: Yeb Havinga
• Re: Bad query plan inside EXISTS clause
  • From: Grzegorz Jaśkiewicz
• Re: Bad query plan inside EXISTS clause
  • From: Kenneth Marshall
• Bad query plan inside EXISTS clause
  • From: Benoit Delbosc
• Re: Strange workaround for slow query
  • From: Yeb Havinga
• Re: Strange workaround for slow query
  • From: sverhagen
• Re: Strange workaround for slow query
  • From: Yeb Havinga
• Re: Strange workaround for slow query
  • From: sverhagen
• Re: Strange workaround for slow query
  • From: Yeb Havinga
• Strange workaround for slow query
  • From: Kees van Dieren
• Strange workaround for slow query
  • From: sverhagen
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Scott Carey
• Re: 10K vs 15k rpm for analytics
  • From: Scott Carey
• Re: Deleting Large Objects
  • From: Kevin Grittner
• Deleting Large Objects
  • From: John KEA
• Re: Extracting superlatives - SQL design philosophy
  • From: Dave Crooke
• Re: 10K vs 15k rpm for analytics
  • From: Michael Stone
• Re: Out of shared memory in postgres 8.4.2 and locks
  • From: Merlin Moncure
• Re: 10K vs 15k rpm for analytics
  • From: Kevin Grittner
• Re: 10K vs 15k rpm for analytics
  • From: david
• Re: 10K vs 15k rpm for analytics
  • From: Ing. Marcos Ortiz Valmaseda
• Re: 10K vs 15k rpm for analytics
  • From: Pierre C
• Re: Out of shared memory in postgres 8.4.2 and locks
  • From: Vidhya Bondre
• Re: Extracting superlatives - SQL design philosophy
  • From: Merlin Moncure
• Re: Out of shared memory in postgres 8.4.2 and locks
  • From: Merlin Moncure
• Out of shared memory in postgres 8.4.2 and locks
  • From: Vidhya Bondre
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Scott Carey
• Re: 10K vs 15k rpm for analytics
  • From: Scott Carey
• Re: partition pruning
  • From: Simon Riggs
• Re: Estimation issue with partitioned tables
  • From: Robert Haas
• Re: Testing FusionIO
  • From: Ben Chobot
• Re: Testing FusionIO
  • From: Greg Smith
• Re: Paritioning vs. caching
  • From: Josh Berkus
• Re: Paritioning vs. caching
  • From: Anj Adu
• Paritioning vs. caching
  • From: Konrad Garus
• Re: Testing FusionIO
  • From: Ben Chobot
• Re: prepared statements and partitioning (partition elimination not working)
  • From: Kenneth Marshall
• prepared statements and partitioning (partition elimination not working)
  • From: Kevin Kempter
• Re: Testing FusionIO
  • From: Łukasz Jagiełło
• Re: Testing FusionIO
  • From: Yeb Havinga
• Testing FusionIO
  • From: Devrim GÜNDÜZ
• Re: Estimation issue with partitioned tables
  • From: Josh Berkus
• Re: partition pruning
  • From: Robert Haas
• Re: Estimation issue with partitioned tables
  • From: Robert Haas
• Re: Estimation issue with partitioned tables
  • From: Josh Berkus
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Robert Haas
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: Estimation issue with partitioned tables
  • From: Robert Haas
• Re: dbt2 performance
  • From: Robert Haas
• Re: SSD + RAID
  • From: Ron Mayer
• Re: 10K vs 15k rpm for analytics
  • From: Yeb Havinga
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Pierre C
• Re: 10K vs 15k rpm for analytics
  • From: Yeb Havinga
• Re: 10K vs 15k rpm for analytics
  • From: Yeb Havinga
• Re: 10K vs 15k rpm for analytics
  • From: Yeb Havinga
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: GiST index performance
  • From: Bruce Momjian
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: Query slowing down significantly??
  • From: Kris Jurka
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: david
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: david
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Dave Crooke
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Yeb Havinga
• 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: No hash join across partitioned tables?
  • From: Grzegorz Jaśkiewicz
• Re: GiST index performance
  • From: Robert Haas
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: GiST index performance
  • From: Robert Haas
• Re: No hash join across partitioned tables?
  • From: Robert Haas
• Re: SSD + RAID
  • From: Pierre C
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: Query slowing down significantly??
  • From: Yeb Havinga
• partition pruning
  • From: Anj Adu
• Re: Query slowing down significantly??
  • From: Rainer Pruy
• Re: Query slowing down significantly??
  • From: Tom Lane
• Re: Query slowing down significantly??
  • From: Rainer Pruy
• Re: Query slowing down significantly??
  • From: Tom Lane
• Re: Autovacuum Tuning advice
  • From: Plugge, Joe R.
• Query slowing down significantly??
  • From: Rainer Pruy
• Re: Autovacuum Tuning advice
  • From: Grzegorz Jaśkiewicz
• Re: Autovacuum Tuning advice
  • From: Plugge, Joe R.
• Re: Autovacuum Tuning advice
  • From: Greg Williamson
• Re: Autovacuum Tuning advice
  • From: Scott Marlowe
• Autovacuum Tuning advice
  • From: Plugge, Joe R.
• Re: [HACKERS] full text search index scan query plan changed in 8.4.2?
  • From: Chris
• Re: partitioned tables query not using indexes
  • From: Josh Berkus
• Re: [HACKERS] full text search index scan query plan changed in 8.4.2?
  • From: Josh Berkus
• Re: partitioned tables query not using indexes
  • From: Kenneth Marshall
• Re: partitioned tables query not using indexes
  • From: Josh Berkus
• Estimation issue with partitioned tables
  • From: Josh Berkus
• Re: How to troubleshoot high mem usage by postgres?
  • From: Tom Lane
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Ron Mayer
• Re: How to troubleshoot high mem usage by postgres?
  • From: Chris
• Re: How to troubleshoot high mem usage by postgres?
  • From: Chris
• Re: How to troubleshoot high mem usage by postgres?
  • From: Tom Lane
• Re: How to troubleshoot high mem usage by postgres?
  • From: Craig Ringer
• Re: How to troubleshoot high mem usage by postgres?
  • From: Ben Chobot
• How to troubleshoot high mem usage by postgres?
  • From: Chris
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Fernando Hevia
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Jorge Montero
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Ben Chobot
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: Multiple data base on same server
  • From: Ing. Marcos Ortiz Valmaseda
• Re: Multiple data base on same server
  • From: elias ghanem
• Re: Multiple data base on same server
  • From: Craig James
• Re: Multiple data base on same server
  • From: elias ghanem
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Kevin Grittner
• Re: Multiple data base on same server
  • From: Richard Huxton
• Re: Multiple data base on same server
  • From: Richard Huxton
• Multiple data base on same server
  • From: elias ghanem
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Greg Smith
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Devrim GÜNDÜZ
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Devrim GÜNDÜZ
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Jochen Erwied
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: No hash join across partitioned tables?
  • From: Bruce Momjian
• Re: GiST index performance
  • From: Bruce Momjian
• Re: GiST index performance
  • From: Bruce Momjian
• Re: dbt2 performance
  • From: Yu-Ju Hong
• Re: dbt2 performance
  • From: Greg Smith
• dbt2 performance
  • From: Yu-Ju Hong
• Re: Extracting superlatives - SQL design philosophy
  • From: Tom Lane
• Re: Extracting superlatives - SQL design philosophy
  • From: Julien Theulier
• Re: Extracting superlatives - SQL design philosophy
  • From: Pierre C
• Re: Extracting superlatives - SQL design philosophy
  • From: Richard Huxton
• Re: Extracting superlatives - SQL design philosophy
  • From: Dave Crooke
• Re: Extracting superlatives - SQL design philosophy
  • From: Richard Huxton
• Re: Extracting superlatives - SQL design philosophy
  • From: Craig James
• Re: Extracting superlatives - SQL design philosophy
  • From: Dave Crooke
• Re: Extracting superlatives - SQL design philosophy
  • From: George Sexton
• Re: Extracting superlatives - SQL design philosophy
  • From: George Sexton
• Re: Extracting superlatives - SQL design philosophy
  • From: Garrett Murphy
• Re: Extracting superlatives - SQL design philosophy
  • From: Mose
• Extracting superlatives - SQL design philosophy
  • From: Dave Crooke
• Re: partitioned tables query not using indexes
  • From: Kevin Kempter
• Re: partitioned tables query not using indexes
  • From: A. Kretschmer
• Re: Internal operations when the planner makes a hash join.
  • From: Igor Neyman
• partitioned tables query not using indexes
  • From: Kevin Kempter
• Re: SSD + RAID
  • From: Dave Crooke
• Re: Planner question - "bit" data types
  • From: Scott Carey
• Thx and additional Q's .....
  • From: Dave Crooke
• Re: Internal operations when the planner makes a hash join.
  • From: Kevin Grittner
• Re: Internal operations when the planner makes a hash join.
  • From: negora
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Ben Chobot
• Re: Internal operations when the planner makes a hash join.
  • From: Kevin Grittner
• Re: Internal operations when the planner makes a hash join.
  • From: negora
• Re: SSD + RAID
  • From: Mark Mielke
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: SSD + RAID
  • From: david
• Re: SSD + RAID
  • From: Aidan Van Dyk
• Re: SSD + RAID
  • From: david
• Re: Internal operations when the planner makes a hash join.
  • From: Scott Carey
• Re: SSD + RAID
  • From: Scott Carey
• Re: Internal operations when the planner makes a hash join.
  • From: Alvaro Herrera
• Re: Internal operations when the planner makes a hash join.
  • From: negora
• Re: Internal operations when the planner makes a hash join.
  • From: Kevin Grittner
• Internal operations when the planner makes a hash join.
  • From: negora
• Internal operations when the planner makes a hash join.
  • From: negora
• Re: Slow query: table iteration (8.3)
  • From: Yeb Havinga
• Re: SSD + RAID
  • From: Nikolas Everett
• Re: SSD + RAID
  • From: Pierre C
• Re: SSD + RAID
  • From: david
• Re: Advice requested on structuring aggregation queries
  • From: Joe Conway
• Advice requested on structuring aggregation queries
  • From: Dave Crooke
• Re: Planner question - "bit" data types
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Scott Marlowe
• Re: SSD + RAID
  • From: Scott Marlowe
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Mark Mielke
• Re: SSD + RAID
  • From: Greg Smith
• Re: plpgsql plan cache
  • From: Joel Jacobson
• Re: plpgsql plan cache
  • From: Pierre C
• Re: plpgsql plan cache
  • From: Nikolas Everett
• Re: plpgsql plan cache
  • From: Tom Lane
• Re: plpgsql plan cache
  • From: Joel Jacobson
• Re: plpgsql plan cache
  • From: Pierre C
• plpgsql plan cache
  • From: Joel Jacobson
• Re: SSD + RAID
  • From: Ron Mayer
• Re: shared_buffers
  • From: Kevin Grittner
• shared_buffers
  • From: George Sexton
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: AutoVacuum_NapTime
  • From: Alvaro Herrera
• Re: SSD + RAID
  • From: Arjen van der Meijden
• Re: SSD + RAID
  • From: Greg Smith
• Re: Auto Vacuum out of memory
  • From: Robert Haas
• Re: SSD + RAID
  • From: Ron Mayer
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Scott Carey
• Re: can we optimize STACK_DEPTH_SLOP
  • From: terry
• Re: can we optimize STACK_DEPTH_SLOP
  • From: Tom Lane
• can we optimize STACK_DEPTH_SLOP
  • From: terry
• can we optimize STACK_DEPTH_SLOP
  • From: terry
• Re: AutoVacuum_NapTime
  • From: George Sexton
• Re: AutoVacuum_NapTime
  • From: Tom Lane
• AutoVacuum_NapTime
  • From: George Sexton
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Dan Langille
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: bgwriter tunables vs pg_stat_bgwriter
  • From: Jeff
• Re: index usage in not like
  • From: A. Kretschmer
• Re: index usage in not like
  • From: Thom Brown
• Re: index usage in not like
  • From: Kenneth Marshall
• Re: index usage in not like
  • From: A. Kretschmer
• Re: index usage in not like
  • From: Thom Brown
• Re: index usage in not like
  • From: Thom Brown
• index usage in not like
  • From: AI Rumman
• Michael Clemmons wants to stay in touch on LinkedIn
  • From: Michael Clemmons
• Re: bgwriter tunables vs pg_stat_bgwriter
  • From: Greg Smith
• Re: bgwriter tunables vs pg_stat_bgwriter
  • From: Brad Nicholson
• Re: disk space usage unexpected
  • From: Rose Zhou
• Re: disk space usage unexpected
  • From: Ben Chobot
• bgwriter tunables vs pg_stat_bgwriter
  • From: Jeff
• Re: Dell PERC H700/H800
  • From: Stefan Kaltenbrunner
• Re: 8.1 -> 8.4 regression
  • From: Tom Lane
• Re: another 8.1->8.4 regression
  • From: Ben Chobot
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Jeff Davis
• another 8.1->8.4 regression
  • From: Ben Chobot
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: Why index is not using here?
  • From: Kevin Grittner
• Re: Dell PERC H700/H800
  • From: Bruce Momjian
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: Kevin Grittner
• Re: Why index is not using here?
  • From: AI Rumman
• Why index is not using here?
  • From: AI Rumman
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: disk space usage unexpected
  • From: Joshua D. Drake
• Re: disk space usage unexpected
  • From: Rose Zhou
• Re: disk space usage unexpected
  • From: Ben Chobot
• Auto Vacuum out of memory
  • From: Rose Zhou
• disk space usage unexpected
  • From: Rose Zhou
• Re: 8.1 -> 8.4 regression
  • From: Ben Chobot
• Re: 8.1 -> 8.4 regression
  • From: Tom Lane
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: Scott Marlowe
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Robert Haas
• Re: 8.1 -> 8.4 regression
  • From: Ben Chobot
• Re: 8.1 -> 8.4 regression
  • From: Kevin Grittner
• Re: Why primary key index are not using in joining?
  • From: Tom Lane
• Re: PostgreSQL on SMP Architectures
  • From: Kevin Grittner
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: Kevin Grittner
• Re: Why primary key index are not using in joining?
  • From: Yeb Havinga
• Re: 8.1 -> 8.4 regression
  • From: Dennis Björklund
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: Why primary key index are not using in joining?
  • From: Scott Marlowe
• Why primary key index are not using in joining?
  • From: AI Rumman
• Re: PostgreSQL on SMP Architectures
  • From: Boszormenyi Zoltan
• Re: PostgreSQL on SMP Architectures
  • From: Reydan Cankur
• 8.1 -> 8.4 regression
  • From: Ben Chobot
• Re: PostgreSQL on SMP Architectures
  • From: Scott Marlowe
• Re: PostgreSQL on SMP Architectures
  • From: Arjen van der Meijden
• PostgreSQL on SMP Architectures
  • From: Reydan Cankur
• Re: Deferred constraint and delete performance
  • From: Віталій Тимчишин
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Pierre Frédéric Caillaud
• Re: Dell PERC H700/H800
  • From: Scott Marlowe
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: Dell PERC H700/H800
  • From: Greg Smith
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Greg Smith
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: Kevin Grittner
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Alvaro Herrera
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Tom Lane
• Re: Dell PERC H700/H800
  • From: Dave Crooke
• Re: Questions on plan with INSERT/SELECT on partitioned table
  • From: Tom Lane
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Kevin Grittner
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Karl Denninger
• Questions on plan with INSERT/SELECT on partitioned table
  • From: Connors, Bill
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Kevin Grittner
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Karl Denninger
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Kevin Grittner
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: Kevin Grittner
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Alvaro Herrera
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Alvaro Herrera
• Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: Immutable table functions
  • From: Yeb Havinga
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Immutable table functions
  • From: Luiz Angelo Daros de Luca
• Re: Dell PERC H700/H800
  • From: Scott Marlowe
• Re: Dell PERC H700/H800
  • From: Łukasz Jagiełło
• Re: Dell PERC H700/H800
  • From: James Mansion
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Aidan Van Dyk
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Alvaro Herrera
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: Dell PERC H700/H800
  • From: Scott Marlowe
• Re: Dell PERC H700/H800
  • From: Joshua D. Drake
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Scott Marlowe
• Re: perf problem with huge table
  • From: Leo Mannhart
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Robert Haas
• Dell PERC H700/H800
  • From: Matthew Wakeling
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Bruce Momjian
• Re: perf problem with huge table
  • From: jesper
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Tom Lane
• Re: How exactly PostgreSQL allocates memory for its needs?
  • From: Scott Marlowe
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: david
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: perf problem with huge table
  • From: Greg Smith
• Re: perf problem with huge table
  • From: Dave Crooke
• Re: perf problem with huge table
  • From: Jon Lewison
• Re: perf problem with huge table
  • From: Dave Crooke
• Re: perf problem with huge table
  • From: Jon Lewison
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Jorge Montero
• Re: perf problem with huge table
  • From: Dave Crooke
• Re: perf problem with huge table
  • From: Justin Graf
• perf problem with huge table
  • From: rama
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Robert Haas
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Scott Carey
• Re: Deferred constraint and delete performance
  • From: Andres Freund
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Jeff
• Re: How exactly PostgreSQL allocates memory for its needs?
  • From: Justin Graf
• Re: PostgreSQL - case studies
  • From: Stephen Frost
• Re: PostgreSQL - case studies
  • From: Kevin Grittner
• Re: [GENERAL] PostgreSQL - case studies
  • From: Ing. Marcos L. Ortiz Valmaseda
• Re: Deferred constraint and delete performance
  • From: Tom Lane
• Deferred constraint and delete performance
  • From: Franck Routier
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Pavel Stehule
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Scott Marlowe
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: [GENERAL] PostgreSQL - case studies
  • From: Scott Marlowe
• How exactly PostgreSQL allocates memory for its needs?
  • From: Anton Maksimenkov
• Re: PostgreSQL - case studies
  • From: Amitabh Kant
• 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• PostgreSQL - case studies
  • From: Jayadevan M
• Re: DISTINCT vs. GROUP BY
  • From: Dimi Paun
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Jeff
• Re: DISTINCT vs. GROUP BY
  • From: Tom Lane
• Re: DISTINCT vs. GROUP BY
  • From: Thom Brown
• DISTINCT vs. GROUP BY
  • From: Dimi Paun
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Amitabh Kant
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Jesper Krogh
• moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: foreign key constraint lock behavour in postgresql
  • From: Albe Laurenz
• Re: [GENERAL] index is not using
  • From: Scott Marlowe
• Re: [GENERAL] index is not using
  • From: Guillaume Lelarge
• Re: index is not using?
  • From: Scott Marlowe
• index is not using?
  • From: AI Rumman
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: david
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Scott Carey
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Mark Wong
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Scott Marlowe
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Stark
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Josh Berkus
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Kevin Grittner
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Albe Laurenz
• Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: foreign key constraint lock behavour in postgresql
  • From: Albe Laurenz
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Alvaro Herrera
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Tom Lane
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Smith
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: Slow query: table iteration (8.3)
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Smith
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: index on partitioned table
  • From: Robert Haas
• Re: foreign key constraint lock behavour in postgresql
  • From: Robert Haas
• Re: index on partitioned table
  • From: Nikolas Everett
• index on partitioned table
  • From: Wojtek
• Re: Slow query: table iteration (8.3)
  • From: Yeb Havinga
• Re: foreign key constraint lock behavour in postgresql
  • From: Albe Laurenz
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: foreign key constraint lock behavour in postgresql
  • From: Robert Haas
• Re: Slow-ish Query Needs Some Love
  • From: Robert Haas
• Re: Slow query: table iteration (8.3)
  • From: Robert Haas
• Re: bigint integers up to 19 digits.
  • From: Alvaro Herrera
• Re: bigint integers up to 19 digits.
  • From: Jochen Erwied
• Re: bigint integers up to 19 digits.
  • From: Tory M Blue
• Re: bigint integers up to 19 digits.
  • From: Alvaro Herrera
• Re: bigint integers up to 19 digits.
  • From: Craig James
• bigint integers up to 19 digits.
  • From: Tory M Blue
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Matthew Wakeling
• Re: Air-traffic benchmark
  • From: Simon Riggs
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Ivan Voras
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: Slow query: table iteration (8.3)
  • From: Grzegorz Jaśkiewicz
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: some problems when i use postgresql 8.4.2 in my projects .
  • From: Pierre Frédéric Caillaud
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: foreign key constraint lock behavour in postgresql
  • From: david
• Re: System overload / context switching / oom, 8.3
  • From: Greg Smith
• foreign key constraint lock behavour in postgresql
  • From: wangyuxiang
• Re: Slow query: table iteration (8.3)
  • From: Robert Haas
• Re: System overload / context switching / oom, 8.3
  • From: Rob Lemley
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Greg Smith
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Robert Haas
• Re: System overload / context switching / oom, 8.3
  • From: Robert Haas
• Re: Queries within a function
  • From: Mridula Mahadevan
• Re: Slow-ish Query Needs Some Love
  • From: Andy Colson
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Andy Colson
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Ivan Voras
• Re: Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Reid Thompson
• Re: Queries within a function
  • From: Віталій Тимчишин
• Re: queries with subquery constraints on partitioned tables not optimized?
  • From: Nikolas Everett
• Re: some problems when i use postgresql 8.4.2 in my projects .
  • From: Leo Mannhart
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: some problems when i use postgresql 8.4.2 in my projects .
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Stark
• Re: System overload / context switching / oom, 8.3
  • From: Matthew Wakeling
• Re: queries with subquery constraints on partitioned tables not optimized?
  • From: Dimitri Fontaine
• Re: the jokes for pg concurrency write performance
  • From: J Sisson
• Re: System overload / context switching / oom, 8.3
  • From: Greg Smith
• Re: the jokes for pg concurrency write performance
  • From: Greg Smith
• Re: Queries within a function
  • From: ramasubramanian
• some problems when i use postgresql 8.4.2 in my projects .
  • From: wyx6fox
• Re: queries with subquery constraints on partitioned tables not optimized?
  • From: Tom Lane
• Slow-ish Query Needs Some Love
  • From: Matt White
• queries with subquery constraints on partitioned tables not optimized?
  • From: Davor J.
• Re: Slow-ish Query Needs Some Love
  • From: Edgardo Portal
• Re: Slow-ish Query Needs Some Love
  • From: Matt White
• Re: System overload / context switching / oom, 8.3
  • From: Rob
• Re: System overload / context switching / oom, 8.3
  • From: Rob
• Re: Queries within a function
  • From: Mridula Mahadevan
• Re: System overload / context switching / oom, 8.3
  • From: Andy Colson
• Re: Queries within a function
  • From: Mridula Mahadevan
• Re: System overload / context switching / oom, 8.3
  • From: Andy Colson
• Re: System overload / context switching / oom, 8.3
  • From: Kevin Grittner
• Re: System overload / context switching / oom, 8.3
  • From: Scott Marlowe
• Re: Slow-ish Query Needs Some Love
  • From: Andy Colson
• Re: Re: 回复：Re: [PERFORM] the jokes for pg concurrency write performance
  • From: Tom Lane
• Re: Queries within a function
  • From: "Ing. Marcos Orti­z Valmaseda"
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Tom Lane
• Re: Queries within a function
  • From: Tom Lane
• System overload / context switching / oom, 8.3
  • From: Rob
• Re: Queries within a function
  • From: Pavel Stehule
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: use pgsql in a big project, but i found pg has some big problem on concurrency write operation, maybe a joke for myself !
  • From: Greg Stark
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Queries within a function
  • From: Mridula Mahadevan
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: the jokes for pg concurrency write performance
  • From: Scott Marlowe
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Tom Lane
• Re: 回复：Re: [PERFORM] the jokes for pg concurrency write performance
  • From: Richard Broersma
• Re: the jokes for pg concurrency write performance
  • From: Alvaro Herrera
• Re: the jokes for pg concurrency write performance
  • From: Scott Marlowe
• Re: Slow query: table iteration (8.3)
  • From: Yeb Havinga
• Sincere apology for my insults and hand-waving in these mails:the jokes for pg concurrency write performance
  • From: wyx6fox
• Re: the jokes for pg concurrency write performance
  • From: Richard Broersma
• Re: the jokes for pg concurrency write performance
  • From: david
• Re: use pgsql in a big project, but i found pg has some big problem on concurrency write operation, maybe a joke for myself !
  • From: Kevin Grittner
• the jokes for pg concurrency write performance
  • From: wyx6fox
• use pgsql in a big project, but i found pg has some big problem on concurrency write operation, maybe a joke for myself !
  • From: wyx6fox
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: Slow query: table iteration (8.3)
  • From: Yeb Havinga
• Re: Constraint propagating for equal fields
  • From: Віталій Тимчишин
• Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: Constraint propagating for equal fields
  • From: Greg Stark
• Re: Limited Shared Buffer Problem
  • From: Greg Smith
• Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Stark
• Re: Limited Shared Buffer Problem
  • From: **Rod MacNeil
• Re: Limited Shared Buffer Problem
  • From: Cédric Villemain
• Re: Limited Shared Buffer Problem
  • From: jose javier parra sanchez
• Re: Limited Shared Buffer Problem
  • From: "Ing . Marcos Luís Ortíz Valmaseda"
• Re: Limited Shared Buffer Problem
  • From: Scott Marlowe
• Re: Limited Shared Buffer Problem
  • From: Richard Neill
• Limited Shared Buffer Problem
  • From: **Rod MacNeil
• Constraint propagating for equal fields
  • From: Віталій Тимчишин
• Re: Benchmark shows very slow bulk delete
  • From: Ivan Voras
• Re: Benchmark shows very slow bulk delete
  • From: Greg Smith
• Re: Benchmark shows very slow bulk delete
  • From: James Mansion
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Віталій Тимчишин
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Matthew Wakeling
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Віталій Тимчишин
• Re: Benchmark shows very slow bulk delete
  • From: Andres Freund
• Re: test send (recommended by Dave Page)
  • From: Dave Page
• Re: Benchmark shows very slow bulk delete
  • From: Nikolas Everett
• Re: test send (recommended by Dave Page)
  • From: Matthew Wakeling
• test send (recommended by Dave Page)
  • From: Mark Steben
• Re: Benchmark shows very slow bulk delete
  • From: Kevin Grittner
• Re: Benchmark shows very slow bulk delete
  • From: Matthew Wakeling
• Re: Benchmark shows very slow bulk delete
  • From: Ivan Voras
• Benchmark shows very slow bulk delete
  • From: Thom Brown
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Smith
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Greg Smith
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Greg Smith
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Scott Carey
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Scott Carey
• Re: Poor query plan across OR operator
  • From: Kevin Grittner
• Re: Poor query plan across OR operator
  • From: Tom Lane
• Re: splitting data into multiple tables
  • From: Greg Smith