Postgres Performance Date Index

• Thread Index

• Re: optimize query with a maximum(date) extraction
  • From: Gregory Stark
• Re: optimize query with a maximum(date) extraction
  • From: Gregory Stark
• FW: optimize query with a maximum(date) extraction
  • From: Gregory Williamson
• optimize query with a maximum(date) extraction
  • From: JS Ubei
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Hannes Dorbath
• Re: Vacum Analyze problem
  • From: Gregory Stark
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Alvaro Herrera
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: join tables vs. denormalization by trigger
  • From: Marc Mamin
• Performance on 8CPU's and 32GB of RAM
  • From: Carlo Stonebanks
• Re: join tables vs. denormalization by trigger
  • From: Mark Lewis
• Re: About autovacuum
  • From: Bill Moran
• join tables vs. denormalization by trigger
  • From: Walter Mauritz
• Re: Vacum Analyze problem
  • From: Richard Broersma Jr
• Re: Vacum Analyze problem
  • From: rafael
• About autovacuum
  • From: Jean-David Beyer
• Re: Vacum Analyze problem
  • From: Bill Moran
• Re: Vacum Analyze problem
  • From: Kevin Kempter
• Re: Vacum Analyze problem
  • From: rafael
• Re: Vacum Analyze problem
  • From: Mikko Partio
• Vacum Analyze problem
  • From: rafael
• Re: Slow Query
  • From: Kevin Grittner
• Re: schemas to limit data access
  • From: Merlin Moncure
• Re: Slow Query
  • From: Tom Lane
• Re: Slow Query
  • From: Shawn
• Re: Slow Query
  • From: Kevin Grittner
• Re: Slow Query
  • From: Kevin Grittner
• Re: Slow Query
  • From: Shawn
• Re: Slow Query
  • From: Shawn
• Re: Slow Query
  • From: Kevin Grittner
• Re: Slow Query
  • From: Tom Lane
• Re: Slow Query
  • From: Shawn
• Re: [GENERAL] Performance issue with nested loop
  • From: Decibel!
• Re: Slow Query
  • From: Shawn
• Re: Slow Query
  • From: Tom Lane
• Slow Query
  • From: Shawn
• schemas to limit data access
  • From: Brennan, Sean (IMS)
• schemas to limit data access
  • From: Brennan, Sean (IMS)
• schemas to limit data access
  • From: Brennan, Sean (IMS)
• Re: Fwd: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Mark Lewis
• Re: 8.2 Autovacuum BUG ?
  • From: Tom Lane
• Re: Fwd: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Tom Lane
• Re: 8.2 Autovacuum BUG ?
  • From: Greg Smith
• Re: 8.2 Autovacuum BUG ?
  • From: Chris Browne
• Re: 8.2 Autovacuum BUG ?
  • From: Tom Lane
• Re: [Solved] Postgres performance problem
  • From: Vivek Khera
• Re: 8.2 Autovacuum BUG ?
  • From: Erik Jones
• Re: 8.2 Autovacuum BUG ?
  • From: Tom Lane
• Re: 8.2 Autovacuum BUG ?
  • From: Alvaro Herrera
• Re: 8.2 Autovacuum BUG ?
  • From: Alvaro Herrera
• Re: 8.2 Autovacuum BUG ?
  • From: Pallav Kalva
• Re: 8.2 Autovacuum BUG ?
  • From: Mikko Partio
• Re: 8.2 Autovacuum BUG ?
  • From: Chris Browne
• Re: 8.2 Autovacuum BUG ?
  • From: Mark Lewis
• Re: 8.2 Autovacuum BUG ?
  • From: Pallav Kalva
• Re: 8.2 Autovacuum BUG ?
  • From: Alvaro Herrera
• Re: 8.2 Autovacuum BUG ?
  • From: Pallav Kalva
• Re: 8.2 Autovacuum BUG ?
  • From: Tom Lane
• 8.2 Autovacuum BUG ?
  • From: Pallav Kalva
• Re: [Solved] Postgres performance problem
  • From: Richard Huxton
• Re: [Solved] Postgres performance problem
  • From: Mark Lewis
• Re: [Solved] Postgres performance problem
  • From: Decibel!
• Re: [Solved] Postgres performance problem
  • From: Ruben Rubio
• Re: Postgres performance problem
  • From: ruben
• Re: Shared memory usage
  • From: Max Zorloff
• Re: Transaction Log
  • From: Alan Hodgson
• Re: Transaction Log
  • From: Bill Moran
• Re: Transaction Log
  • From: Steinar H. Gunderson
• Re: Transaction Log
  • From: Steve Atkins
• Re: Transaction Log
  • From: Mark Mielke
• Transaction Log
  • From: Markus Benne
• Transaction Log
  • From: mbguy2000-1
• Re: Shared memory usage
  • From: Greg Smith
• Re: LIKE query verses =
  • From: Tom Lane
• Re: LIKE query verses =
  • From: Mark Lewis
• LIKE query verses =
  • From: Karthikeyan Mahadevan
• Re: Performance across multiple schemas
  • From: Robins Tharakan
• Performance issue with nested loop
  • From: Jens Reufsteck
• Re: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Evan Carroll
• Performance issue with nested loop
  • From: Jens Reufsteck
• Re: Performance problem with table containing a lot of text (blog)
  • From: Heikki Linnakangas
• Re: Performance problem with table containing a lot of text (blog)
  • From: Kari Lavikka
• Re: Performance problem with table containing a lot of text (blog)
  • From: Heikki Linnakangas
• Re: index & Bitmap Heap Scan
  • From: Paul
• Re: Performance across multiple schemas
  • From: Robins
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Decibel!
• Re: 8.2.4 Chooses Bad Query Plan
  • From: Tom Lane
• Re: 8.2.4 Chooses Bad Query Plan
  • From: Pallav Kalva
• Re: Performance problem with table containing a lot of text (blog)
  • From: Kari Lavikka
• Re: Performance problem with table containing a lot of text (blog)
  • From: Dan Harris
• Performance problem with table containing a lot of text (blog)
  • From: Kari Lavikka
• Re: Fwd: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Tom Lane
• Re: Postgres performance problem
  • From: Anton Melser
• Re: 8.2.4 Chooses Bad Query Plan
  • From: Tom Lane
• Re: index & Bitmap Heap Scan
  • From: Tom Lane
• Re: Fwd: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Mark Lewis
• Re: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Evan Carroll
• Fwd: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Evan Carroll
• Re: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Kevin Grittner
• Re: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Joshua D. Drake
• Re: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Gregory Stark
• Re: 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Scott Marlowe
• 8.2 Query 10 times slower than 8.1 (view-heavy)
  • From: Evan Carroll
• 8.2.4 Chooses Bad Query Plan
  • From: Pallav Kalva
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Erik Jones
• Bitmap Heap Scan before using index
  • From: GOERGLER Paul
• Performance issue
  • From: Willo van der Merwe
• Re: Optimising "in" queries
  • From: Stephen Davies
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Kenneth Marshall
• Re: Optimising "in" queries
  • From: Stephen Davies
• Re: Autovacuum is running forever
  • From: Sachchida Ojha
• Re: server performance issues - suggestions for tuning
  • From: Scott Marlowe
• Re: server performance issues - suggestions for tuning
  • From: Andrew Sullivan
• Re: Performance across multiple schemas
  • From: Tom Lane
• Re: Performance across multiple schemas
  • From: Robins
• Re: server performance issues - suggestions for tuning
  • From: Kevin Grittner
• Performance across multiple schemas
  • From: Robins
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Heikki Linnakangas
• Re: Performance issue
  • From: Willo van der Merwe
• index & Bitmap Heap Scan
  • From: Paul
• Re: server performance issues - suggestions for tuning
  • From: Richard Huxton
• server performance issues - suggestions for tuning
  • From: Kevin Kempter
• Re: significant vacuum issues - looking for suggestions
  • From: Kevin Kempter
• Re: significant vacuum issues - looking for suggestions
  • From: Kevin Kempter
• Re: significant vacuum issues - looking for suggestions
  • From: Decibel!
• Re: significant vacuum issues - looking for suggestions
  • From: Kevin Kempter
• Re: significant vacuum issues - looking for suggestions
  • From: Kevin Grittner
• Re: asynchronous commit feature
  • From: Merlin Moncure
• Re: significant vacuum issues - looking for suggestions
  • From: Decibel!
• Re: asynchronous commit feature
  • From: Decibel!
• Re: Performance issue
  • From: Tom Lane
• Re: Performance issue
  • From: Bill Moran
• Performance issue
  • From: Willo van der Merwe
• Re: Postgres performance problem
  • From: Bill Moran
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Tomas Tamosaitis
• Re: Postgres performance problem
  • From: ruben
• Re: Postgres performance problem
  • From: Chris Mair
• Re: Shared memory usage
  • From: Max Zorloff
• Postgres performance problem
  • From: Ruben Rubio
• Re: Shared memory usage
  • From: Adam Tauno Williams
• Re: [GENERAL] Shared memory usage
  • From: Max Zorloff
• Re: [GENERAL] Shared memory usage
  • From: Max Zorloff
• Re: [GENERAL] Shared memory usage
  • From: Martijn van Oosterhout
• Shared memory usage
  • From: Max Zorloff
• Re: [GENERAL] Partioning tsearch2 a table into chunks and accessing via views
  • From: Erik Jones
• Re: Partioning tsearch2 a table into chunks and accessing via views
  • From: Erik Jones
• Re: [GENERAL] Partioning tsearch2 a table into chunks and accessing via views
  • From: Benjamin Arai
• Re: [GENERAL] Partioning tsearch2 a table into chunks and accessing via views
  • From: Joshua D. Drake
• Re: [GENERAL] Partioning tsearch2 a table into chunks and accessing via views
  • From: Brandon Shalton
• Re: [GENERAL] Partioning tsearch2 a table into chunks and accessing via views
  • From: Benjamin Arai
• Re: [GENERAL] Partioning tsearch2 a table into chunks and accessing via views
  • From: Joshua D. Drake
• Re: significant vacuum issues - looking for suggestions
  • From: Kevin Kempter
• Re: [GENERAL] Partioning tsearch2 a table into chunks and accessing via views
  • From: Benjamin Arai
• Re: [GENERAL] Partioning tsearch2 a table into chunks and accessing via views
  • From: Joshua D. Drake
• Re: Partioning tsearch2 a table into chunks and accessing via views
  • From: Brandon Shalton
• Partioning tsearch2 a table into chunks and accessing via views
  • From: Benjamin Arai
• Re: When/if to Reindex
  • From: Tom Lane
• Re: significant vacuum issues - looking for suggestions
  • From: Tom Lane
• Re: significant vacuum issues - looking for suggestions
  • From: Bill Moran
• Re: significant vacuum issues - looking for suggestions
  • From: Kevin Grittner
• Re: significant vacuum issues - looking for suggestions
  • From: Bill Moran
• Re: When/if to Reindex
  • From: Gregory Stark
• significant vacuum issues - looking for suggestions
  • From: Kevin Kempter
• Re: When/if to Reindex
  • From: Steven Flatt
• Re: When/if to Reindex
  • From: Tom Lane
• Re: When/if to Reindex
  • From: Steven Flatt
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Luke Lonergan
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Luke Lonergan
• Re: When/if to Reindex
  • From: Tom Lane
• Re: When/if to Reindex
  • From: Steven Flatt
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Heikki Linnakangas
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Anton
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Mikko Partio
• partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Anton
• Re: When/if to Reindex
  • From: Gregory Stark
• Re: When/if to Reindex
  • From: Mark Kirkwood
• Re: When/if to Reindex
  • From: Tom Lane
• Re: Optimising "in" queries
  • From: Tom Lane
• Re: When/if to Reindex
  • From: Steven Flatt
• Re: Raid Configurations
  • From: Decibel!
• Re: Optimising "in" queries
  • From: Alvaro Herrera
• Re: long-running query - needs tuning
  • From: Tom Lane
• Re: deadlock_timeout parameter in Postgresql.cof
  • From: Bill Moran
• deadlock_timeout parameter in Postgresql.cof
  • From: Sachchida Ojha
• deadlock_timeout parameter in Postgresql.cof
  • From: Sachchida Ojha
• Re: Optimising "in" queries
  • From: Stephen Davies
• Re: Installing PostgreSQL
  • From: Campbell, Lance
• Re: Installing PostgreSQL
  • From: Richard Huxton
• Re: Installing PostgreSQL
  • From: Greg Smith
• Re: Installing PostgreSQL
  • From: Campbell, Lance
• long-running query - needs tuning
  • From: Kevin Kempter
• Re: Installing PostgreSQL
  • From: Richard Huxton
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Greg Smith
• Installing PostgreSQL
  • From: Campbell, Lance
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Dmitry Potapov
• asynchronous commit feature
  • From: Merlin Moncure
• Re: Optimising "in" queries
  • From: Russell Smith
• Re: Optimising "in" queries
  • From: Russell Smith
• Re: Optimising "in" queries
  • From: Michael Glaesemann
• Re: When/if to Reindex
  • From: Gregory Stark
• Re: Long running transaction in pg_activity_log
  • From: Farhan Mughal
• Re: Long running transaction in pg_activity_log
  • From: Tobias Brox
• Re: Fast tsearch2, trigram matching on short phrases
  • From: Carlo Stonebanks
• Re: Long running transaction in pg_activity_log
  • From: Sachchida Ojha
• Long running transaction in pg_activity_log
  • From: Sachchida Ojha
• Re: Fast tsearch2, trigram matching on short phrases
  • From: Oleg Bartunov
• Re: Fast tsearch2, trigram matching on short phrases
  • From: Carlo Stonebanks
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Greg Smith
• Re: Fast tsearch2, trigram matching on short phrases
  • From: Carlo Stonebanks
• Re: Optimising "in" queries
  • From: Kevin Grittner
• Re: Fast tsearch2, trigram matching on short phrases
  • From: Oleg Bartunov
• Re: When/if to Reindex
  • From: Steven Flatt
• Re: Fast tsearch2, trigram matching on short phrases
  • From: Steinar H. Gunderson
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Dmitry Potapov
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Dmitry Potapov
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Dmitry Potapov
• Fast tsearch2, trigram matching on short phrases
  • From: Carlo Stonebanks
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Joshua D. Drake
• Re: io storm on checkpoints, postgresql 8.2.4, linux
  • From: Mark Mielke
• io storm on checkpoints, postgresql 8.2.4, linux
  • From: Dmitry Potapov
• Re: Optimising "in" queries
  • From: Michael Glaesemann
• Re: Optimising "in" queries
  • From: Russell Smith
• Re: Poor Performance after Upgrade
  • From: Russell Smith
• Re: Poor Performance after Upgrade
  • From: vincent
• Re: Poor Performance after Upgrade
  • From: Steinar H. Gunderson
• Re: Optimising "in" queries
  • From: Scott Marlowe
• Poor Performance after Upgrade
  • From: Ben Perrault
• Optimising "in" queries
  • From: Stephen Davies
• Re: Autovacuum is running forever
  • From: Scott Marlowe
• Re: Autovacuum is running forever
  • From: Scott Marlowe
• Re: Autovacuum is running forever
  • From: Sachchida Ojha
• Re: Autovacuum is running forever
  • From: Scott Marlowe
• Re: Autovacuum is running forever
  • From: Scott Marlowe
• Re: Autovacuum is running forever
  • From: Scott Marlowe
• Re: Autovacuum is running forever
  • From: Sachchida Ojha
• Re: Autovacuum is running forever
  • From: Alvaro Herrera
• Re: Autovacuum is running forever
  • From: Sachchida Ojha
• Re: Autovacuum running forever
  • From: Scott Marlowe
• Re: Autovacuum is running forever
  • From: Sachchida Ojha
• Re: Autovacuum is running forever
  • From: Michael Glaesemann
• Re: Autovacuum running forever
  • From: Sachchida Ojha
• Autovacuum is running forever
  • From: Sachchida Ojha
• Re: Performance Solaris vs Linux
  • From: Julius Stroffek
• Re: Terminology Question
  • From: Joshua D. Drake
• Re: Terminology Question
  • From: Scott Marlowe
• Terminology Question
  • From: Campbell, Lance
• Re: Help optimize view
  • From: Relyea, Mike
• Re: [pgsql-jobs] Looking for database hosting
  • From: Andrew Hammond
• Re: schema design question
  • From: Adam Tauno Williams
• Re: [pgsql-jobs] Looking for database hosting
  • From: Leon Mergen
• Re: Looking for database hosting: FIX CC LIST!!
  • From: Josh Berkus
• Re: schema design question
  • From: Steinar H. Gunderson
• Re: schema design question
  • From: David Fetter
• Re: [pgsql-jobs] Looking for database hosting
  • From: Luke Lonergan
• Re: schema design question
  • From: mark overmeer
• Re: [pgsql-jobs] Looking for database hosting
  • From: Andrew Hammond
• Re: schema design question
  • From: David Fetter
• Re: schema design question
  • From: Steinar H. Gunderson
• Re: schema design question
  • From: David Fetter
• Re: schema design question
  • From: mark overmeer
• Re: schema design question
  • From: Adam Tauno Williams
• schema design question
  • From: mark overmeer
• Re: Help optimize view
  • From: Kevin Grittner
• Re: Help optimize view
  • From: Kevin Grittner
• Re: Fwd: Table Partitioning
  • From: Henrik
• Re: Performance Solaris vs Linux
  • From: Chris Mair
• Re: Performance Solaris vs Linux
  • From: Alvaro Herrera
• Re: Simple select hangs while CPU close to 100% - Analyze
  • From: Alvaro Herrera
• Re: select count(*) performance
  • From: Scott Marlowe
• Re: Raid Configurations
  • From: Merlin Moncure
• Fwd: Table Partitioning
  • From: Nurlan Mukhanov
• Performance Solaris vs Linux
  • From: Fredrik Bertilsson
• Raid Configurations
  • From: Robert D Oden
• Re: select count(*) performance
  • From: Detlef Rudolph
• Help optimize view
  • From: Relyea, Mike
• Stable function optimisation
  • From: Philipp Specht
• Re: Simple select hangs while CPU close to 100% - Analyze
  • From: Jozsef Szalay
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Guy Rouillier
• Re: Bad planner decision - bitmap scan instead of index
  • From: Frank Schoep
• Re: Bad planner decision - bitmap scan instead of index
  • From: Michael Stone
• Re: Bad planner decision - bitmap scan instead of index
  • From: Frank Schoep
• Re: Bad planner decision - bitmap scan instead of index
  • From: hubert depesz lubaczewski
• Re: Integrated perc 5/i
  • From: Luke Lonergan
• Re: Indexscan is only used if we use "limit n"
  • From: Josh Berkus
• Re: Integrated perc 5/i
  • From: Decibel!
• Re: Integrated perc 5/i
  • From: Scott Marlowe
• Re: Integrated perc 5/i
  • From: Merlin Moncure
• Re: Integrated perc 5/i
  • From: tyrrill_ed
• Re: Integrated perc 5/i
  • From: Decibel!
• Re: Bad planner decision - bitmap scan instead of index
  • From: Frank Schoep
• Re: Integrated perc 5/i
  • From: Steinar H. Gunderson
• Re: Integrated perc 5/i
  • From: Luke Lonergan
• Re: Integrated perc 5/i
  • From: Michael Ben-Nes
• Re: Bad planner decision - bitmap scan instead of index
  • From: Tom Lane
• Re: Integrated perc 5/i
  • From: Steinar H. Gunderson
• Bad planner decision - bitmap scan instead of index
  • From: Frank Schoep
• Re: Integrated perc 5/i
  • From: Merlin Moncure
• Integrated perc 5/i
  • From: Michael Ben-Nes
• Re: Stable function optimisation
  • From: Philipp Specht
• Re: Indexscan is only used if we use "limit n"
  • From: Mark Lewis
• Re: Indexscan is only used if we use "limit n"
  • From: joao
• Re: Indexscan is only used if we use "limit n"
  • From: Alvaro Herrera
• Indexscan is only used if we use "limit n"
  • From: Sebastián Baioni
• Re: RAID 10 or RAID 10 + RAID 1
  • From: Decibel!
• RAID 10 or RAID 10 + RAID 1
  • From: Michael Ben-Nes
• Re: Dell Hardware Recommendations
  • From: Dave Cramer
• Re: [HACKERS] Proposal: Pluggable Optimizer Interface
  • From: Tom Lane
• Re: [HACKERS] Proposal: Pluggable Optimizer Interface
  • From: Josh Berkus
• Re: Help optimize view
  • From: Kevin Grittner
• Re: [HACKERS] Proposal: Pluggable Optimizer Interface
  • From: Tom Lane
• Re: Performance on writable views
  • From: Jim Nasby
• Re: [HACKERS] Proposal: Pluggable Optimizer Interface
  • From: Julius Stroffek
• Re: Help optimize view
  • From: Kevin Grittner
• Re: [HACKERS] Proposal: Pluggable Optimizer Interface
  • From: Tom Lane
• Re: Stable function optimisation
  • From: Tom Lane
• Re: Help optimize view
  • From: Relyea, Mike
• Stable function optimisation
  • From: Philipp Specht
• Re: [HACKERS] Proposal: Pluggable Optimizer Interface
  • From: Stefan Kaltenbrunner
• Re: Help optimize view
  • From: Tom Lane
• Re: Help optimize view
  • From: Kevin Grittner
• Proposal: Pluggable Optimizer Interface
  • From: Julius Stroffek
• Re: Help optimize view
  • From: Relyea, Mike
• Re: Help optimize view
  • From: Kevin Grittner
• Re: How to ENABLE SQL capturing???
  • From: Joshua D. Drake
• Re: How to ENABLE SQL capturing???
  • From: Gregory Stark
• Re: How to ENABLE SQL capturing???
  • From: Joshua D. Drake
• Re: Help optimize view
  • From: Relyea, Mike
• Re: How to ENABLE SQL capturing???
  • From: Jonathan Ellis
• Re: select count(*) performance
  • From: Kevin Grittner
• Re: Dell Hardware Recommendations
  • From: Vivek Khera
• Re: select count(*) performance
  • From: valgog
• Re: select count(*) performance
  • From: Kevin Grittner
• Re: Performance on writable views
  • From: Joshua D. Drake
• Re: Performance on writable views
  • From: Heikki Linnakangas
• Re: How to ENABLE SQL capturing???
  • From: Joshua D. Drake
• Re: Help optimize view
  • From: Tom Lane
• Re: How to ENABLE SQL capturing???
  • From: smiley2211
• Re: How to ENABLE SQL capturing???
  • From: Jeff Frost
• Re: Dell Hardware Recommendations
  • From: Joel Fradkin
• Re: Dell Hardware Recommendations
  • From: Merlin Moncure
• Re: Bitmap Index Scan optimization opportunity
  • From: Heikki Linnakangas
• Re: CLOG Patch
  • From: Simon Riggs
• Re: Dell Hardware Recommendations
  • From: Vivek Khera
• Bitmap Index Scan optimization opportunity
  • From: Kevin Grittner
• Re: Help optimize view
  • From: Relyea, Mike
• Re: CLOG Patch
  • From: Jignesh K. Shah
• Re: How to ENABLE SQL capturing???
  • From: smiley2211
• Re: Dell Hardware Recommendations
  • From: Merlin Moncure
• Re: select count(*) performance
  • From: Brian Hurt
• Re: select count(*) performance
  • From: Merlin Moncure
• Re: Dell Hardware Recommendations
  • From: Merlin Moncure
• Re: Dell Hardware Recommendations
  • From: Merlin Moncure
• Re: Dell Hardware Recommendations
  • From: david
• Implementing an regex filter
  • From: Enrico Weigelt
• Re: Update table performance
  • From: Piotr Kołaczkowski
• select count(*) performance
  • From: runic
• Re: select count(*) performance
  • From: slawekj
• Performance on writable views
  • From: Enrico Weigelt
• Re: Update table performance
  • From: Kenneth Marshall
• Re: Dell Hardware Recommendations
  • From: Greg Smith
• Re: Dell Hardware Recommendations
  • From: Decibel!
• Re: Dell Hardware Recommendations
  • From: Scott Marlowe
• Re: Dell Hardware Recommendations
  • From: Joe Uhl
• Re: Dell Hardware Recommendations
  • From: Arjen van der Meijden
• Re: Dell Hardware Recommendations
  • From: Decibel!
• Re: Dell Hardware Recommendations
  • From: Merlin Moncure
• Re: Dell Hardware Recommendations
  • From: Decibel!
• Dell Hardware Recommendations
  • From: Joe Uhl
• Re: Update table performance
  • From: Decibel!
• Re: mid 2007 "best bang for the buck" hardware opinions
  • From: Vivek Khera
• Re: When/if to Reindex
  • From: Steven Flatt
• Re: Update table performance
  • From: Trevor Talbot
• Re: Update table performance
  • From: Michael Stone
• Re: When/if to Reindex
  • From: Bill Moran
• Re: Update table performance
  • From: Merlin Moncure
• Re: mid 2007 "best bang for the buck" hardware opinions
  • From: justin
• Re: mid 2007 "best bang for the buck" hardware opinions
  • From: Scott Marlowe
• mid 2007 "best bang for the buck" hardware opinions
  • From: justin
• Re: When/if to Reindex
  • From: Tom Lane
• Re: How to ENABLE SQL capturing???
  • From: Bryan Murphy
• Re: When/if to Reindex
  • From: Decibel!
• Re: How to ENABLE SQL capturing???
  • From: Steinar H. Gunderson
• How to ENABLE SQL capturing???
  • From: smiley2211
• Re: When/if to Reindex
  • From: Bill Moran
• Re: When/if to Reindex
  • From: Steven Flatt
• Re: When/if to Reindex
  • From: Vivek Khera
• Re: Update table performance
  • From: Decibel!
• Re: Update table performance
  • From: Erik Jones
• Re: Update table performance
  • From: Heikki Linnakangas
• Re: Update table performance
  • From: Erik Jones
• Re: Update table performance
  • From: Mark Makarowsky
• Re: Update table performance
  • From: Decibel!
• Re: Update table performance
  • From: Scott Marlowe
• Re: Update table performance
  • From: Chris Browne
• Re: Update table performance
  • From: Decibel!
• Re: Update table performance
  • From: Alan Hodgson
• Re: Update table performance
  • From: Scott Marlowe
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Scott Marlowe
• Re: Update table performance
  • From: Richard Huxton
• Update table performance
  • From: Mark Makarowsky
• Re: [GENERAL] Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Tom Lane
• Re: [GENERAL] Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Henrik Zagerholm
• Re: Extreme slow select query 8.2.4
  • From: Henrik Zagerholm
• Re: Extreme slow select query 8.2.4
  • From: Heikki Linnakangas
• Re: TRUNCATE TABLE
  • From: Tom Lane
• Re: Default Performance between 8.0 and 8.1
  • From: Ted Jordan
• Re: Extreme slow select query 8.2.4
  • From: Henrik Zagerholm
• Re: [GENERAL] Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Tom Lane
• Re: Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Gregory Stark
• Re: Extreme slow select query 8.2.4
  • From: Tom Lane
• Re: Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Henrik Zagerholm
• Re: Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Gregory Stark
• Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Henrik Zagerholm
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Sven Clement
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Heikki Linnakangas
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Ragnar
• Extreme slow select query 8.2.4
  • From: Henrik Zagerholm
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Sven Clement
• Re: TRUNCATE TABLE
  • From: Decibel!
• Re: Default Performance between 8.0 and 8.1
  • From: Merlin Moncure
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Heikki Linnakangas
• Re: TRUNCATE TABLE
  • From: Adriaan van Os
• Default Performance between 8.0 and 8.1
  • From: Ted Jordan
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Sven Clement
• RES: RES: RES: Improving select peformance
  • From: Carlos H. Reimer
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Tom Lane
• Re: cpu throttling
  • From: Decibel!
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Andrew Kroeger
• Re: CLOG Patch
  • From: Simon Riggs
• CLOG Patch
  • From: Jignesh K. Shah
• Re: Postgres optimizer
  • From: Mark Lewis
• Postgres optimizer
  • From: Mouhamadou Dia
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Josh Berkus
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Sven Clement
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Dan Langille
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Mark Lewis
• Performance problems with large telemetric datasets on 7.4.2
  • From: Sven Clement
• Re: RES: RES: Improving select peformance
  • From: Tom Lane
• RES: RES: Improving select peformance
  • From: Carlos H. Reimer
• Re: Why are distinct and group by choosing different plans?
  • From: Tom Lane
• Re: Why are distinct and group by choosing different plans?
  • From: Gregory Stark
• Why are distinct and group by choosing different plans?
  • From: Ron Mayer
• Re: cpu throttling
  • From: Bryan Murphy
• Re: cpu throttling
  • From: Alan Hodgson
• cpu throttling
  • From: Bryan Murphy
• RES: RES: Improving select peformance
  • From: Carlos H. Reimer
• Re: Postgres configuration for 64 CPUs, 128 GB RAM...
  • From: Luke Lonergan
• Re: select on 1milion register = 6s
  • From: Jan Dittmer
• Re: RES: Improving select peformance
  • From: Alvaro Herrera
• RES: Improving select peformance
  • From: Carlos H. Reimer
• Re: TRUNCATE TABLE
  • From: Alvaro Herrera
• Re: TRUNCATE TABLE
  • From: Kevin Grittner
• Re: TRUNCATE TABLE
  • From: Adriaan van Os
• Re: Using EXECUTE in a function
  • From: Merlin Moncure
• Re: Postgres configuration for 64 CPUs, 128 GB RAM...
  • From: Dimitri
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: User concurrency thresholding: where do I look?
  • From: Josh Berkus
• Re: Semantics of PostgreSQL Server Log Stats
  • From: Bruce Momjian
• Re: deadlock detected when calling function (Callfunction_name)
  • From: Sachchida Ojha
• Re: disk filling up
  • From: Merlin Moncure
• Re: deadlock detected when calling function (Call function_name)
  • From: Alvaro Herrera
• Re: deadlock detected when calling function (Call function_name)
  • From: Sachchida Ojha
• Semantics of PostgreSQL Server Log Stats
  • From: Camilo Porto
• Using EXECUTE in a function
  • From: Andreas Tille
• Seq scan on join table despite index and high statistics
  • From: Henrik Zagerholm
• Re: Vacuum looping?
  • From: Decibel!
• Re: disk filling up
  • From: Tom Lane
• Query optimization....
  • From: Karl Denninger
• Re: Postgres configuration for 64 CPUs, 128 GB RAM...
  • From: Luke Lonergan
• Re: Postgres configuration for 64 CPUs, 128 GB RAM...
  • From: Dimitri
• Re: multicolumn index column order
  • From: Lew
• Re: Questions on Tags table schema
  • From: Ron Mayer
• Re: Slow query with backwards index scan
  • From: Nis Jørgensen
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: Slow query with backwards index scan
  • From: Tilmann Singer
• Re: Slow query with backwards index scan
  • From: Nis Jørgensen
• Re: Vacuum looping?
  • From: Steven Flatt
• Re: Questions on Tags table schema
  • From: Richard Huxton
• Re: Questions on Tags table schema
  • From: Richard Huxton
• Re: Questions on Tags table schema
  • From: Jay Kang
• Re: Questions on Tags table schema
  • From: Richard Huxton
• Re: Questions on Tags table schema
  • From: Richard Huxton
• Re: Questions on Tags table schema
  • From: Jay Kang
• Re: Questions on Tags table schema
  • From: Richard Huxton
• Re: RES: RES: select on 1milion register = 6s
  • From: Decibel!
• Re: RES: RES: select on 1milion register = 6s
  • From: Decibel!
• Re: select on 1milion register = 6s
  • From: Alvaro Herrera
• RES: RES: select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• Re: RES: select on 1milion register = 6s
  • From: Decibel!
• Questions on Tags table schema
  • From: Jay Kang
• Re: select on 1milion register = 6s
  • From: Scott Marlowe
• RES: select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• RES: select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• RES: RES: select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• Re: RES: select on 1milion register = 6s
  • From: Ragnar
• Re: Slow query with backwards index scan
  • From: Tilmann Singer
• Re: Slow query with backwards index scan
  • From: andrew
• RES: select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• Re: Slow query with backwards index scan
  • From: Jeremy Harris
• Re: Slow query with backwards index scan
  • From: Craig James
• Re: select on 1milion register = 6s
  • From: Hervé Piedvache
• Re: select on 1milion register = 6s
  • From: Craig James
• select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• Re: Slow query with backwards index scan
  • From: Tilmann Singer
• Re: Slow query with backwards index scan
  • From: andrew
• Re: Vacuum looping?
  • From: Jim C. Nasby
• Re: Vacuum looping?
  • From: Tom Lane
• Re: Slow query with backwards index scan
  • From: Tilmann Singer
• Vacuum looping?
  • From: Steven Flatt
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: Slow query with backwards index scan
  • From: Nis Jørgensen
• Re: How to use a trigger to write rows to a remote server
  • From: Merlin Moncure
• Slow query with backwards index scan
  • From: Tilmann Singer
• Re: disk filling up
  • From: Merlin Moncure
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: User concurrency thresholding: where do I look?
  • From: Simon Riggs
• Re: User concurrency thresholding: where do I look?
  • From: Simon Riggs
• Re: User concurrency thresholding: where do I look?
  • From: Alvaro Herrera
• Re: disk filling up
  • From: Yudhvir Singh Sidhu
• Re: disk filling up
  • From: Mark Kirkwood
• Re: update, truncate and vacuum
  • From: Dave Dutcher
• Re: Affect of Reindexing on Vacuum Times
  • From: Jim Nasby
• Re: update, truncate and vacuum
  • From: Luke Lonergan
• update, truncate and vacuum
  • From: Scott Feldstein
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: User concurrency thresholding: where do I look?
  • From: Simon Riggs
• Re: User concurrency thresholding: where do I look?
  • From: Robert Lor
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: performance of postgresql in replication using slony
  • From: Chris Browne
• Re: performance of postgresql in replication using slony
  • From: Jeff Davis
• Re: User concurrency thresholding: where do I look?
  • From: Simon Riggs
• Re: User concurrency thresholding: where do I look?
  • From: Tom Lane
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: User concurrency thresholding: where do I look?
  • From: Simon Riggs
• Re: disk filling up
  • From: Joshua D. Drake
• Re: User concurrency thresholding: where do I look?
  • From: Tom Lane
• Re: disk filling up
  • From: Mark Lewis
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: disk filling up
  • From: Bill Moran
• disk filling up
  • From: Brandon Shalton
• performance of postgresql in replication using slony
  • From: angga erwina
• [no subject]
  • From: Unknown
• Delete Cascade FK speed issue
  • From: Patric de Waha
• Re: Join with lower/upper limits doesn't scale well
  • From: Gregory Stark
• Join with lower/upper limits doesn't scale well
  • From: Craig James
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Greg Smith
• Re: slow query
  • From: Nis Jørgensen
• slow query
  • From: Vidhya Bondre
• [PERFORMANCE] is it possible to force an index to be held in memory?
  • From: valgog
• Re:
  • From: Ed Tyrrill
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Tom Lane
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Tom Lane
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Tom Lane
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Craig James
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Alvaro Herrera
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Richard Huxton
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Ho Fat Tsang
• Re: How to install Postgresql 8.2.x on windows XP silently
  • From: Magnus Hagander
• How to install Postgresql 8.2.x on windows XP silently
  • From: Sachchida Ojha
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Tom Lane
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Kevin Grittner
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Gregory Stark
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Greg Smith
• Re: High IOWAIT times, low iops? Need Help with configuration
  • From: Greg Smith
• Re: High IOWAIT times, low iops? Need Help with configuration
  • From: Evan Reiser
• Re: update query taking too long
  • From: Richard Huxton
• Re: update query taking too long
  • From: Heikki Linnakangas
• Re: update query taking too long
  • From: Jean-David Beyer
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Richard Huxton
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Ho Fat Tsang
• Re: update query taking too long
  • From: Chris
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Richard Huxton
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Ho Fat Tsang
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Richard Huxton
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Andreas Kostyrka
• Re: High IOWAIT times, low iops? Need Help with configuration
  • From: Richard Huxton
• Re: update query taking too long
  • From: Richard Huxton
• PostgreSQL 8.0 occasionally slow down
  • From: Ho Fat Tsang
• Re: update query taking too long
  • From: Chris
• Re: update query taking too long
  • From: Richard Huxton
• Re: update query taking too long
  • From: Chris
• Re: update query taking too long
  • From: A. Kretschmer
• Re: update query taking too long
  • From: Chris
• Re: update query taking too long
  • From: Chris
• Re: update query taking too long
  • From: Tom Lane
• Re: update query taking too long
  • From: A. Kretschmer
• update query taking too long
  • From: Chris
• High IOWAIT times, low iops? Need Help with configuration
  • From: Evan Reiser
• Re: Volunteer to build a configuration tool
  • From: Josh Berkus
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Josh Berkus
• rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Greg Smith
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Josh Berkus
• Re: Database-wide VACUUM ANALYZE
  • From: Alvaro Herrera
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Greg Smith
• Re: Database-wide VACUUM ANALYZE
  • From: Steven Flatt
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Josh Berkus
• Re: Volunteer to build a configuration tool
  • From: Gregory Stark
• Re: Volunteer to build a configuration tool
  • From: Jim Nasby
• Re: Database-wide VACUUM ANALYZE
  • From: Jim Nasby
• Re:
  • From: Tom Lane
• Re:
  • From: Stephen Frost
• Re:
  • From: Ed Tyrrill
• Re:
  • From: Stephen Frost
• Re:
  • From: Ed Tyrrill
• Re: startup caching suggestions
  • From: Bryan Murphy
• Re: startup caching suggestions
  • From: Oleg Bartunov
• Re:
  • From: Tom Lane
• Re:
  • From: Stephen Frost
• Non-optimal query plan with 8.2
  • From: Tyrrill, Ed
• [no subject]
  • From: Tyrrill, Ed
• startup caching suggestions
  • From: Bryan Murphy
• Re: PITR Backups
  • From: Tom Lane
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Tom Lane
• Re: PITR Backups
  • From: Gregory Stark
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Simon Riggs
• Re: PITR Backups
  • From: Tom Lane
• Re: PITR Backups
  • From: Simon Riggs
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Gregory Stark
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Gregory Stark
• Re: PITR Backups
  • From: Tom Lane
• Re: Slow indexscan
  • From: Tom Lane
• Re: PITR Backups
  • From: Simon Riggs
• Re: Performance query about large tables, lots of concurrent access
  • From: Jean-David Beyer
• Re: PostgreSQL Configuration Tool for Dummies - feedback adjustable control
  • From: Sabin Coanda
• Re: Performance query about large tables, lots of concurrent access
  • From: Michael Stone
• Re: PITR Backups
  • From: Koichi Suzuki
• Is AIX Concurrent IO safe with PostgreSQL?
  • From: Dawid Kuroczko
• Re: Slow indexscan
  • From: Mikko Partio
• Re: PREPARE and stuff
  • From: PFC
• Re: PREPARE and stuff
  • From: Gregory Stark
• Re: PREPARE and stuff
  • From: Andreas Kostyrka
• Re: PREPARE and stuff
  • From: Heikki Linnakangas
• PREPARE and stuff
  • From: PFC
• Re: PostgreSQL Configuration Tool for Dummies - feedback adjustable control
  • From: Greg Smith
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Greg Smith
• Re: Volunteer to build a configuration tool
  • From: Greg Smith
• Re: Slow join query
  • From: Scott Marlowe
• Re: Slow join query
  • From: Tom Tamulewicz
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Slow join query
  • From: Michael Glaesemann
• Re: Slow join query
  • From: Tom Tamulewicz
• Re: Slow join query
  • From: Michael Glaesemann
• Re: PostgreSQL Configuration Tool for Dummies - feedback adjustable control
  • From: david
• Slow join query
  • From: Tom Tamulewicz
• Re: PITR Backups
  • From: Tom Lane
• Re: PITR Backups
  • From: Simon Riggs
• Re: PITR Backups
  • From: Tom Lane
• Re: Data transfer very slow when connected via DSL
  • From: Dimitri
• Re: PITR Backups
  • From: Gregory Stark
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Data transfer very slow when connected via DSL
  • From: Joshua D. Drake
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Database-wide VACUUM ANALYZE
  • From: Alvaro Herrera