Postgres Performance Date Index

• Thread Index

• Re: Can anyone make this code tighter? Too slow, Please help!
  • From: Mark Stosberg
• cube operations slower than geo_distance() on production server
  • From: Mark Stosberg
• Re: Recreate big table
  • From: Daniel Cristian Cruz
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Recreate big table
  • From: Gábriel Ákos
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Alvaro Herrera
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: minshall
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• Disk saturation
  • From: Carlos H. Reimer
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: Speed up this query
  • From: Mark Stosberg
• stats collector process high CPU utilization
  • From: Benjamin Minshall
• tip: faster sorting for proximity queries by using cube_distance()
  • From: Mark Stosberg
• Re: Help Needed
  • From: Richard Huxton
• Help Needed
  • From: Muruganantham M
• Re: How long should it take to insert 200,000 records?
  • From: Tom Lane
• Re: How long should it take to insert 200,000 records?
  • From: Mark Kirkwood
• Re: How long should it take to insert 200,000 records?
  • From: Karen Hill
• Re: index scan through a subquery
  • From: Bill Howe
• Re: How long should it take to insert 200,000 records?
  • From: Mark Lewis
• Re: How long should it take to insert 200,000 records?
  • From: Merlin Moncure
• Re: How long should it take to insert 200,000 records?
  • From: Bruno Wolff III
• Re: How long should it take to insert 200,000 records?
  • From: Mark Lewis
• Re: How long should it take to insert 200,000 records?
  • From: Hiltibidal, Robert
• Re: How long should it take to insert 200,000 records?
  • From: Merlin Moncure
• Re: How long should it take to insert 200,000 records?
  • From: Scott Marlowe
• Re: How long should it take to insert 200,000 records?
  • From: Merlin Moncure
• Re: How long should it take to insert 200,000 records?
  • From: Scott Marlowe
• Re: explain analyze output for review (was: optimizing a geo_distance()...)
  • From: Bruno Wolff III
• Re: explain analyze output for review (was: optimizing a geo_distance()...)
  • From: Hiltibidal, Robert
• Re: explain analyze output: vacuuming made a big difference.
  • From: Mark Stosberg
• Re: explain analyze output for review (was: optimizing a geo_distance()...)
  • From: Adam Rich
• Re: explain analyze output for review (was: optimizing a geo_distance()...)
  • From: Hiltibidal, Robert
• Re: explain analyze output for review (was: optimizing a geo_distance()...)
  • From: Mark Stosberg
• Re: optimizing a geo_distance() proximity query (example and benchmark)
  • From: Merlin Moncure
• Re: Tuning
  • From: Harald Armin Massa
• Re: How long should it take to insert 200,000 records?
  • From: Csaba Nagy
• Re: index scan through a subquery
  • From: Tom Lane
• Re: optimizing a geo_distance() proximity query (example and benchmark)
  • From: Bruno Wolff III
• Re: How long should it take to insert 200,000 records?
  • From: Tom Lane
• How long should it take to insert 200,000 records?
  • From: Karen Hill
• Re: optimizing a geo_distance() proximity query (example and benchmark)
  • From: Mark Stosberg
• Re: optimizing a geo_distance() proximity query
  • From: Bruno Wolff III
• Re: optimizing a geo_distance() proximity query
  • From: Merlin Moncure
• Re: optimizing a geo_distance() proximity query
  • From: Mark Stosberg
• Re: trouble with a join on OS X
  • From: Shane Ambler
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: optimizing a geo_distance() proximity query
  • From: Bruno Wolff III
• Re: optimizing a geo_distance() proximity query
  • From: Oleg Bartunov
• optimizing a geo_distance() proximity query
  • From: Mark Stosberg
• Re: trouble with a join on OS X
  • From: Shane Ambler
• Re: trouble with a join on OS X
  • From: Tom Lane
• Re: trouble with a join on OS X
  • From: Joshua D. Drake
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Tom Lane
• Re: trouble with a join on OS X
  • From: Joshua D. Drake
• Re: trouble with a join on OS X
  • From: Geoffrey
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Joshua D. Drake
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Luke Lonergan
• Re: trouble with a join on OS X
  • From: Joshua D. Drake
• Re: trouble with a join on OS X
  • From: Luke Lonergan
• Re: trouble with a join on OS X
  • From: Tom Lane
• OT: Mac OS X disk buffer cache
  • From: Kevin Murphy
• Re: drive configuration for a new server
  • From: Ben
• Re: drive configuration for a new server
  • From: Jeff Frost
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Tom Lane
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Tom Lane
• Re: trouble with a join on OS X
  • From: Steinar H. Gunderson
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Kirk Wythers
• Re: trouble with a join on OS X
  • From: Tom Lane
• Re: trouble with a join on OS X
  • From: Gábriel Ákos
• Re: trouble with a join on OS X
  • From: Richard Huxton
• Re: trouble with a join on OS X
  • From: Steinar H. Gunderson
• trouble with a join on OS X
  • From: Kirk Wythers
• Re: Subselect query enhancement
  • From: Richard Huxton
• index scan through a subquery
  • From: Bill Howe
• drive configuration for a new server
  • From: Ben
• Re: Subselect query enhancement
  • From: Andrew Lazarus
• Re: int4 vs varchar to store ip addr
  • From: Michael Artz
• Re: Subselect query enhancement
  • From: Michael Artz
• Re: Subselect query enhancement
  • From: Richard Huxton
• Re: Subselect query enhancement
  • From: Michael Artz
• Re: Subselect query enhancement
  • From: Frank Wiles
• Re: Subselect query enhancement
  • From: Michael Artz
• Re: Subselect query enhancement
  • From: Ted Allen
• Re: Subselect query enhancement
  • From: Richard Huxton
• Subselect query enhancement
  • From: Michael Artz
• Using statement_timeout as a performance tool?
  • From: Mark Stosberg
• [no subject]
  • From: Unknown
• Re: Slow update
  • From: Tomas Vondra
• Re: Very slow queries
  • From: Chad Wagner
• Slow update
  • From: Abu Mushayeed
• Re: Tuning
  • From: Mischa Sandberg
• Re: Very slow queries
  • From: Sidar López Cruz
• Re: Querying distinct values from a large table
  • From: Tom Lane
• Re: Very slow queries
  • From: Sidar López Cruz
• Re: Querying distinct values from a large table
  • From: Ron
• Re: Very slow queries
  • From: Ted Allen
• Re: Very slow queries
  • From: Sidar López Cruz
• Re: Querying distinct values from a large table
  • From: Gregory Stark
• Re: Querying distinct values from a large table
  • From: Luke Lonergan
• Re: Querying distinct values from a large table
  • From: Tom Lane
• Re: Querying distinct values from a large table
  • From: Luke Lonergan
• Re: Querying distinct values from a large table
  • From: Alvaro Herrera
• Re: Querying distinct values from a large table
  • From: Josh Berkus
• Re: Very slow queries
  • From: Chad Wagner
• Re: Very slow queries
  • From: Ted Allen
• Re: Very slow queries
  • From: Sidar López Cruz
• Very slow queries
  • From: Sidar López Cruz
• Re: Querying distinct values from a large table
  • From: Steinar H. Gunderson
• Re: Querying distinct values from a large table
  • From: Luke Lonergan
• Re: Querying distinct values from a large table
  • From: Alvaro Herrera
• Re: Querying distinct values from a large table
  • From: Bruno Wolff III
• Re: Querying distinct values from a large table
  • From: Gregory Stark
• Re: Querying distinct values from a large table
  • From: Luke Lonergan
• Re: Querying distinct values from a large table
  • From: Chad Wagner
• Re: Querying distinct values from a large table
  • From: Luke Lonergan
• Re: Bad Row Count Estimate on View with 8.2
  • From: Dave Dutcher
• Re: Querying distinct values from a large table
  • From: Brian Herlihy
• Re: Querying distinct values from a large table
  • From: Chad Wagner
• Re: Querying distinct values from a large table
  • From: Richard Huxton
• Re: Querying distinct values from a large table
  • From: Simon Riggs
• Re: Querying distinct values from a large table
  • From: imad
• Re: int4 vs varchar to store ip addr
  • From: Pomarede Nicolas
• Re: Partitioning
  • From: Rigmor Ukuhe
• Re: Tuning
  • From: John Parnefjord
• Re: Querying distinct values from a large table
  • From: Richard Huxton
• Re: Querying distinct values from a large table
  • From: Igor Lobanov
• Re: Querying distinct values from a large table
  • From: Igor Lobanov
• Re: Querying distinct values from a large table
  • From: Richard Huxton
• Querying distinct values from a large table
  • From: Igor Lobanov
• Re: Partitioning
  • From: Tomas Vondra
• Partitioning
  • From: Abu Mushayeed
• Thanks All!
  • From: Saranya Sivakumar
• Re: [OT] Very strange postgresql behaviour
  • From: Carlos Moreno
• Re: int4 vs varchar to store ip addr
  • From: Cosimo Streppone
• Re: int4 vs varchar to store ip addr
  • From: Florian Weimer
• int4 vs varchar to store ip addr
  • From: Pomarede Nicolas
• Re: Tuning
  • From: Ron
• Re: [OT] Very strange postgresql behaviour
  • From: Arnau
• Re: work-mem how do I identify the proper size
  • From: Bill Moran
• Re: [OT] Very strange postgresql behaviour
  • From: Heikki Linnakangas
• Re: [OT] Very strange postgresql behaviour
  • From: Bill Moran
• [OT] Very strange postgresql behaviour
  • From: Arnau
• work-mem how do I identify the proper size
  • From: Campbell, Lance
• Re: Tuning
  • From: Tom Lane
• Re: Tuning
  • From: Josh Berkus
• Re: work_mem
  • From: Bill Moran
• Re: work-mem
  • From: imad
• work-mem
  • From: Campbell, Lance
• Re: Bad Row Count Estimate on View with 8.2
  • From: Tom Lane
• Re: Bad Row Count Estimate on View with 8.2
  • From: Dave Dutcher
• Re: IN operator causes sequential scan (vs. multiple OR expressions)
  • From: Ryan Holmes
• Re: IN operator causes sequential scan (vs. multiple OR expressions)
  • From: Tom Lane
• Re: IN operator causes sequential scan (vs. multiple OR expressions)
  • From: Ryan Holmes
• Re: IN operator causes sequential scan (vs. multiple OR expressions)
  • From: Tom Lane
• IN operator causes sequential scan (vs. multiple OR expressions)
  • From: Ryan Holmes
• Re: Seqscan/Indexscan still a known issue?
  • From: Carlos Moreno
• Re: Seqscan/Indexscan still a known issue?
  • From: Tom Lane
• Re: Seqscan/Indexscan still a known issue?
  • From: Carlos Moreno
• Re: Seqscan/Indexscan still a known issue?
  • From: Scott Marlowe
• Re: Seqscan/Indexscan still a known issue?
  • From: Russell Smith
• Re: Seqscan/Indexscan still a known issue?
  • From: Tomas Vondra
• Re: Seqscan/Indexscan still a known issue?
  • From: Guido Neitzer
• Re: Seqscan/Indexscan still a known issue?
  • From: Russell Smith
• Re: Seqscan/Indexscan still a known issue?
  • From: Dennis Bjorklund
• Seqscan/Indexscan still a known issue?
  • From: Carlos Moreno
• Re: [HACKERS] how to plan for vacuum?
  • From: Jim Nasby
• Re: Tuning
  • From: Anton Rommerskirchen
• Re: Tuning
  • From: Dave Cramer
• Tuning
  • From: John Parnefjord
• Re: [HACKERS] how to plan for vacuum?
  • From: Ray Stell
• Re: [HACKERS] how to plan for vacuum?
  • From: Joshua D. Drake
• Re: how to plan for vacuum?
  • From: Jim C. Nasby
• Re: how to plan for vacuum?
  • From: Ray Stell
• Re: how to plan for vacuum?
  • From: Galy Lee
• Re: [HACKERS] how to plan for vacuum?
  • From: Jim C. Nasby
• Re: how to plan for vacuum?
  • From: Alvaro Herrera
• Re: how to plan for vacuum?
  • From: Jim C. Nasby
• Re: slow result
  • From: Shoaib Mir
• Re: Auto Vacuum Problem
  • From: Heiko W.Rupp
• Re: Auto Vacuum Problem
  • From: Richard Huxton
• Re: Postgres processes have a burst of CPU usage
  • From: Richard Huxton
• Auto Vacuum Problem
  • From: Gauri Kanekar
• Re: how to plan for vacuum?
  • From: Galy Lee
• Re: Bad Row Count Estimate on View with 8.2
  • From: Tom Lane
• how to plan for vacuum?
  • From: Galy Lee
• Re: extract(field from timestamp) vs date dimension
  • From: Mark Kirkwood
• Re: slow result
  • From: Mark Kirkwood
• Bad Row Count Estimate on View with 8.2
  • From: Dave Dutcher
• Re: slow result
  • From: Bruno Wolff III
• Re: extract(field from timestamp) vs date dimension
  • From: Merlin Moncure
• Postgres processes have a burst of CPU usage
  • From: Subramaniam Aiylam
• Re: slow result
  • From: Ron
• Re: slow result
  • From: Bill Moran
• Re: extract(field from timestamp) vs date dimension
  • From: Tobias Brox
• Re: extract(field from timestamp) vs date dimension
  • From: Chad Wagner
• extract(field from timestamp) vs date dimension
  • From: Tobias Brox
• Re: slow result
  • From: A. Kretschmer
• slow result
  • From: Laurent Manchon
• Re: slow result
  • From: Steinar H. Gunderson
• Re: slow result
  • From: Steinar H. Gunderson
• Re: slow result
  • From: A. Kretschmer
• Re: slow result
  • From: Heiko W.Rupp
• slow result
  • From: Laurent Manchon
• Re: Table Inheritence and Partioning
  • From: Simon Riggs
• Re: [pgsql-advocacy] Postgres and really huge tables
  • From: Josh Berkus
• Re: DB benchmark and pg config file help
  • From: Kevin Hunter
• Re: Configuration Advice
  • From: Merlin Moncure
• Re: DB benchmark and pg config file help
  • From: Bruno Wolff III
• Re: Postgres and really huge tables
  • From: Merlin Moncure
• Re: DB benchmark and pg config file help
  • From: Kevin Hunter
• Re: DB benchmark and pg config file help
  • From: Merlin Moncure
• Re: [pgsql-advocacy] Postgres and really huge tables
  • From: Oleg Bartunov
• Re: Configuration Advice
  • From: Arjen van der Meijden
• Re: Postgres and really huge tables
  • From: Gavin Sherry
• Re: [pgsql-advocacy] Postgres and really huge tables
  • From: Luke Lonergan
• Re: Configuration Advice
  • From: Tom Lane
• Re: Autoanalyze settings with zero scale factor
  • From: Jeremy Haile
• Re: Postgres and really huge tables
  • From: Tom Lane
• Re: [pgsql-advocacy] Postgres and really huge tables
  • From: Chris Mair
• Re: Autoanalyze settings with zero scale factor
  • From: Tom Lane
• Re: Configuration Advice
  • From: Arjen van der Meijden
• Re: Postgres and really huge tables
  • From: Scott Marlowe
• Re: Autoanalyze settings with zero scale factor
  • From: Matthew T. O'Connor
• Re: [pgsql-advocacy] Postgres and really huge tables
  • From: Joshua D. Drake
• Postgres and really huge tables
  • From: Brian Hurt
• Re: Autoanalyze settings with zero scale factor
  • From: Jeremy Haile
• Re: Autoanalyze settings with zero scale factor
  • From: Matthew T. O'Connor
• Autoanalyze settings with zero scale factor
  • From: Jeremy Haile
• Re: Configuration Advice
  • From: Jeremy Haile
• Re: Configuration Advice
  • From: Arjen van der Meijden
• Re: Configuration Advice
  • From: Scott Marlowe
• Re: Configuration Advice
  • From: Scott Marlowe
• Re: Vacuum v/s Autovacuum
  • From: Shoaib Mir
• Re: Vacuum v/s Autovacuum
  • From: Bill Moran
• Re: Vacuum v/s Autovacuum
  • From: Gauri Kanekar
• Re: Vacuum v/s Autovacuum
  • From: Michael Glaesemann
• Vacuum v/s Autovacuum
  • From: Gauri Kanekar
• Re: Configuration Advice
  • From: Arjen van der Meijden
• Re: Monitoring Transaction Log size
  • From: Shoaib Mir
• Re: Monitoring Transaction Log size
  • From: Simon Riggs
• Re: Version Change
  • From: Michael Glaesemann
• Re: Version Change
  • From: Michael Glaesemann
• Re: Version Change
  • From: Michael Glaesemann
• Version Change
  • From: Gauri Kanekar
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Chris Browne
• Re: Configuration Advice
  • From: Chad Wagner
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Dave Cramer
• Re: Configuration Advice
  • From: Adam Rich
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Scott Marlowe
• Re: Monitoring Transaction Log size
  • From: Tom Lane
• DB benchmark and pg config file help
  • From: Kevin Hunter
• Re: Configuration Advice
  • From: Bruno Wolff III
• Re: Configuration Advice
  • From: Joshua D. Drake
• Re: Configuration Advice
  • From: Benjamin Minshall
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Steve
• Re: Configuration Advice
  • From: Heikki Linnakangas
• Re: Configuration Advice
  • From: Chad Wagner
• Re: Configuration Advice
  • From: Tomas Vondra
• Re: Configuration Advice
  • From: Bricklen Anderson
• Re: Configuration Advice
  • From: Adam Rich
• Configuration Advice
  • From: Steve
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Tomas Vondra
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Tomas Vondra
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Scott Marlowe
• Re: Monitoring Transaction Log size
  • From: Stefan Kaltenbrunner
• Re: Monitoring Transaction Log size
  • From: Shoaib Mir
• Re: Monitoring Transaction Log size
  • From: Joshua D. Drake
• Monitoring Transaction Log size
  • From: Ziegelwanger, Silvio
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Chad Wagner
• Re: [HACKERS] unusual performance for vac following 8.2
  • From: Kim
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Scott Marlowe
• Raid 10 or Raid 5 on Dell PowerEdge
  • From: Dave Dutcher
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Dave Cramer
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Shoaib Mir
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: Table Inheritence and Partioning
  • From: Albert Cervera Areny
• Table Inheritence and Partioning
  • From: ramachandra.bhaskaram
• Re: Table Size
  • From: Guillaume Lelarge
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Scott Marlowe
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Chad Wagner
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Chad Wagner
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: PG8.2.1 choosing slow seqscan over idx scan
  • From: Tom Lane
• PG8.2.1 choosing slow seqscan over idx scan
  • From: Jeremy Haile
• Re: Table Size
  • From: Richard Huxton
• Re: Caching in PostgreSQL
  • From: Chris Browne
• Table Size
  • From: Gauri Kanekar
• Re: Caching in PostgreSQL
  • From: David Levy
• Re: Caching in PostgreSQL
  • From: Heikki Linnakangas
• Re: Caching in PostgreSQL
  • From: ramachandra.bhaskaram
• Re: Caching in PostgreSQL
  • From: Heikki Linnakangas
• Caching in PostgreSQL
  • From: ramachandra.bhaskaram
• FiberChannel cards for FreeBSD on AMD64
  • From: Andrew Hammond
• Re: max() versus order/limit (WAS: High update
  • From: Joshua D. Drake
• Re: pg_trgm performance
  • From: Steinar H. Gunderson
• Re: max() versus order/limit (WAS: High update
  • From: Alvaro Herrera
• Re: max() versus order/limit (WAS: High update activity, PostgreSQL vs BigDBMS)
  • From: Alvaro Herrera
• pg_trgm performance
  • From: Florian Weimer
• Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)
  • From: Rolf Østvik (HA/EXA)
• Re: max() versus order/limit (WAS: High update
  • From: Luke Lonergan
• Re: max() versus order/limit (WAS: High update activity, PostgreSQL vs BigDBMS)
  • From: Adam Rich
• Re: Large table performance
  • From: Luke Lonergan
• Re: Large table performance
  • From: Luke Lonergan
• Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)
  • From: Dave Cramer
• Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)
  • From: Dave Dutcher
• Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)
  • From: Rolf Østvik (HA/EXA)
• Re:
  • From: Dave Cramer
• Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)
  • From: Rolf Østvik (HA/EXA)
• [no subject]
  • From: Rolf Østvik (HA/EXA)
• Re: Large table performance
  • From: Shoaib Mir
• Re: Performance of Parser?
  • From: Dave Cramer
• Re: Large table performance
  • From: Dave Dutcher
• Re: Performance of Parser?
  • From: Tom Lane
• Performance of Parser?
  • From: Jignesh Shah
• Re: Large table performance
  • From: Daniel Cristian Cruz
• Physical separation of tables and indexes - where pg_xlog should go?
  • From: Ireneusz Pluta
• Re: Large table performance
  • From: Steinar H. Gunderson
• Re: Large table performance
  • From: Dave Cramer
• Large table performance
  • From: Mark Dobbrow
• Re: [HACKERS] table partioning performance
  • From: Simon Riggs
• RES: Improving SQL performance
  • From: Carlos H. Reimer
• Partitioning
  • From: Gauri Kanekar
• Re: Planner statistics, correlations
  • From: Heikki Linnakangas
• Re: Planner statistics, correlations
  • From: Tobias Brox
• Re: Planner statistics, correlations
  • From: Heikki Linnakangas
• Re: Planner statistics, correlations
  • From: Tobias Brox
• Re: Planner statistics, correlations
  • From: Richard Huxton
• Re: [HACKERS] unusual performance for vac following 8.2upgrade
  • From: Richard Huxton
• Re: Planner statistics, correlations
  • From: Tobias Brox
• Re: Planner statistics, correlations
  • From: Peter Childs
• Planner statistics, correlations
  • From: Tobias Brox
• Re: [HACKERS] unusual performance for vac following 8.2upgrade
  • From: Tom Lane
• Re: [HACKERS] unusual performance for vac following 8.2upgrade
  • From: Alvaro Herrera
• Re: RES: Improving SQL performance
  • From: Cesar Suga
• Re: [HACKERS] unusual performance for vac following 8.2upgrade
  • From: Simon Riggs
• Re: unusual performance for vac following 8.2 upgrade
  • From: Kim
• Re: [HACKERS] unusual performance for vac following 8.2 upgrade
  • From: Tom Lane
• Re: unusual performance for vac following 8.2 upgrade
  • From: Tom Lane
• Re: unusual performance for vac following 8.2 upgrade
  • From: Kim
• Re: [HACKERS] unusual performance for vac following 8.2 upgrade
  • From: Jim C. Nasby
• RES: Improving SQL performance
  • From: Carlos H. Reimer
• Re: [HACKERS] unusual performance for vac following 8.2 upgrade
  • From: Tom Lane
• Re: [HACKERS] table partioning performance
  • From: Jim C. Nasby
• Re: unusual performance for vac following 8.2 upgrade
  • From: Simon Riggs
• Re: [HACKERS] unusual performance for vac following 8.2 upgrade
  • From: Alvaro Herrera
• Re: unusual performance for vac following 8.2 upgrade
  • From: Tom Lane
• Re: unusual performance for vac following 8.2 upgrade
  • From: Kim
• Re: Improving SQL performance
  • From: Tom Lane
• Re: Improving SQL performance
  • From: Russell Smith
• Re: unusual performance for vac following 8.2 upgrade
  • From: Tom Lane
• Re: unusual performance for vac following 8.2 upgrade
  • From: Tom Lane
• Improving SQL performance
  • From: Carlos H. Reimer
• Re: unusual performance for vac following 8.2 upgrade
  • From: Russell Smith
• unusual performance for vac following 8.2 upgrade
  • From: Kim
• Re: Partitioning
  • From: Bernd Helmle
• Re: Partitioning
  • From: Adam Rich
• Re: Partitioning
  • From: Jeremy Haile
• Re: Partitioning
  • From: Mikael Carneholm
• Re: Partitioning
  • From: Bernd Helmle
• Re: table partioning performance
  • From: Simon Riggs
• Re: Does it matters the column order in indexes and constraints
  • From: Richard Huxton
• Does it matters the column order in indexes and constraints creation?
  • From: Arnau
• Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum
  • From: Jim C. Nasby
• Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum
  • From: Alvaro Herrera
• Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum
  • From: Jim C. Nasby
• Re: table partioning performance
  • From: Jim C. Nasby
• UNSUBSCRIBE
  • From: andrew
• Re: High inserts, bulk deletes - autovacuum vs scheduled
  • From: Jeremy Haile
• Re: Partitioning
  • From: Scott Marlowe
• Re: table partioning performance
  • From: Steven Flatt
• Re: Partitioning
  • From: Jeremy Haile
• Re: Partitioning
  • From: Scott Marlowe
• Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum
  • From: Jim C. Nasby
• Re: Partitioning
  • From: Jim C. Nasby
• Re: table partioning performance
  • From: Steven Flatt
• Re: Performance of PostgreSQL on Windows vs Linux
  • From: Scott Marlowe
• Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum
  • From: Jim C. Nasby
• Re: Performance of PostgreSQL on Windows vs Linux
  • From: Jeremy Haile
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Jeff Frost
• Re: Partitioning
  • From: Jeremy Haile
• Re: Partitioning
  • From: Erik Jones
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Jim C. Nasby
• Re: table partioning performance
  • From: Jim C. Nasby
• Re: Partitioning
  • From: Jim C. Nasby
• Re: PostgreSQL to host e-mail?
  • From: Jim C. Nasby
• Re: Performance of PostgreSQL on Windows vs Linux
  • From: Jim C. Nasby
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Jim C. Nasby
• Re: performance implications of binary placement
  • From: Jim C. Nasby
• Re: Slow inner join, but left join is fast
  • From: Jeremy Haile
• Re: Slow inner join, but left join is fast
  • From: Tom Lane
• Re: Slow inner join, but left join is fast
  • From: Jeremy Haile
• Re: Slow inner join, but left join is fast
  • From: Jeremy Haile
• Re: Slow inner join, but left join is fast
  • From: Tom Lane
• Re: Slow inner join, but left join is fast
  • From: Jeremy Haile
• Re: Slow inner join, but left join is fast
  • From: Tom Lane
• Re: group by will not use an index?
  • From: tsuraan
• Slow inner join, but left join is fast
  • From: Jeremy Haile
• Re: Horribly slow query/ sequential scan
  • From: Tom Lane
• Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum
  • From: Florian Weimer
• Re: Horribly slow query/ sequential scan
  • From: Tom Lane
• Re: group by will not use an index?
  • From: Andrew Lazarus
• Re: group by will not use an index?
  • From: Steinar H. Gunderson
• Re: group by will not use an index?
  • From: Brian Herlihy
• Re: group by will not use an index?
  • From: Scott Marlowe
• Re: Horribly slow query/ sequential scan
  • From: Gregory S. Williamson
• Re: group by will not use an index?
  • From: Adam Rich
• group by will not use an index?
  • From: tsuraan
• Re: High inserts, bulk deletes - autovacuum vs scheduled
  • From: Jeremy Haile
• Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum
  • From: Florian Weimer
• High inserts, bulk deletes - autovacuum vs scheduled vacuum
  • From: Jeremy Haile
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Jeff Frost
• Re: Postgresql Configutation and overflow
  • From: Jim C. Nasby
• Re: Horribly slow query/ sequential scan
  • From: Plugge, Joe R.
• Re: Horribly slow query/ sequential scan
  • From: Tom Lane
• Re: Horribly slow query/ sequential scan
  • From: Dave Cramer
• Re: Running PG on cluster files systems
  • From: Devrim GUNDUZ
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Rolf Østvik
• Running PG on cluster files systems
  • From: Hannes Dorbath
• Re: Horribly slow query/ sequential scan
  • From: Gregory S. Williamson
• Re: Horribly slow query/ sequential scan
  • From: Nörder-Tuitje, Marcus
• Re: Horribly slow query/ sequential scan
  • From: Gregory S. Williamson
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Jim C. Nasby
• Re: table partioning performance
  • From: Simon Riggs
• Re: Horribly slow query/ sequential scan
  • From: db
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Jim C. Nasby
• Horribly slow query/ sequential scan
  • From: Gregory S. Williamson
• Re: table partioning performance
  • From: Merlin Moncure
• Re: table partioning performance
  • From: Steven Flatt
• Re: Slow Query on Postgres 8.2
  • From: Dave Dutcher
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Bruce Momjian
• Re: table partioning performance
  • From: Luke Lonergan
• Re: tweaking under repeatable load
  • From: Dimitri Fontaine
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Adam Rich
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Guy Rouillier
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Adam Rich
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Guy Rouillier
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Joshua D. Drake
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Tom Lane
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Adam Rich
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Craig A. James
• tweaking under repeatable load
  • From: Ben
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Dave Cramer
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Shane Ambler
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Craig A. James
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Joshua D. Drake
• table partioning performance
  • From: Colin Taylor
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Guy Rouillier
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Guy Rouillier
• Re: Missing the point of autovacuum
  • From: Tom Lane
• Re: Missing the point of autovacuum
  • From: Tobias Brox
• Missing the point of autovacuum
  • From: Daryl Herzmann
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Simon Riggs
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Dave Cramer
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Craig A. James
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Guy Rouillier
• Re: PostgreSQL to host e-mail?
  • From: Reid Thompson
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Rolf Østvik
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Erik Jones
• Re: Partitioning
  • From: Mikael Carneholm
• Partitioning
  • From: Arnau
• Re: PostgreSQL to host e-mail?
  • From: Grega Bremec
• Re: Slow Query on Postgres 8.2
  • From: Tom Lane
• Re: Slow Query on Postgres 8.2
  • From: Dave Dutcher
• Re: Slow Query on Postgres 8.2
  • From: Dave Dutcher
• Re: Slow Query on Postgres 8.2
  • From: Adam Rich
• Re: Slow Query on Postgres 8.2
  • From: Tom Lane
• Slow Query on Postgres 8.2
  • From: Dave Dutcher
• Re: PostgreSQL to host e-mail?
  • From: Matthew Schumacher
• Re: PostgreSQL to host e-mail?
  • From: Frank Wiles
• Re: PostgreSQL to host e-mail?
  • From: Joshua D. Drake
• PostgreSQL to host e-mail?
  • From: Charles A. Landemaine
• PostgreSQL to host e-mail?
  • From: Charles A. Landemaine
• Re: Performance of PostgreSQL on Windows vs Linux
  • From: Jeremy Haile
• Re: Performance of PostgreSQL on Windows vs Linux
  • From: Tom Lane
• Re: Performance of PostgreSQL on Windows vs Linux
  • From: Jeremy Haile
• Re: Performance of PostgreSQL on Windows vs Linux
  • From: Jeremy Haile
• Re: Trivial function query optimized badly
  • From: Craig A. James
• Re: Trivial function query optimized badly
  • From: Tom Lane
• Re: Trivial function query optimized badly
  • From: Craig A. James
• Re: Trivial function query optimized badly
  • From: Adam Rich
• Trivial function query optimized badly
  • From: Craig A. James
• Re: Performance of PostgreSQL on Windows vs Linux
  • From: Dimitri Fontaine
• Re: Performance of PostgreSQL on Windows vs Linux
  • From: Magnus Hagander
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Erik Jones
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Tom Lane
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Erik Jones
• Performance of PostgreSQL on Windows vs Linux
  • From: Jeremy Haile
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Tom Lane
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Erik Jones
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Erik Jones
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Tom Lane
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Guillaume Smet
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Erik Jones
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Tom Lane
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Erik Jones
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Tom Lane
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Rolf Østvik
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Tom Lane
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Erik Jones
• Re: More 8.2 client issues (Was: [Slow dump?)
  • From: Richard Huxton
• More 8.2 client issues (Was: [Slow dump?)
  • From: Erik Jones
• Re: Config parameters
  • From: Jeremy Haile
• Re: Config parameters
  • From: Scott Marlowe
• Re: Config parameters
  • From: Jeremy Haile
• Re: Config parameters
  • From: Richard Huxton
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Jeff Davis
• Re: Slow dump?
  • From: Erik Jones
• Re: Slow dump?
  • From: Tom Lane
• Re: Config parameters
  • From: Jeremy Haile
• Slow dump?
  • From: Erik Jones
• Re: Config parameters
  • From: Richard Huxton
• Config parameters
  • From: Jeremy Haile
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Tom Lane
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Jeremy Haile
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Lars Heidieker
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Ragnar
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Geoffrey
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Rolf Østvik
• what work_mem needs a query needs?
  • From: Arnau
• Re: glibc double-free error
  • From: Tom Lane
• Re: glibc double-free error
  • From: Craig A. James
• Re: glibc double-free error
  • From: Tom Lane
• glibc double-free error
  • From: Craig A. James
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Tom Lane
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Rolf Østvik
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Rolf Østvik
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Rolf Østvik
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Tom Lane
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Dennis Bjorklund
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Dave Cramer
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Rolf Østvik
• Re: Worse perfomance on 8.2.0 than on 7.4.14
  • From: Claus Guttesen
• Worse perfomance on 8.2.0 than on 7.4.14
  • From: Rolf Østvik
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Guy Rouillier
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Alex Turner
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Jeff Frost
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Alvaro Herrera
• Re: Backup/Restore too slow
  • From: Russell Smith
• Re: URGENT: Out of disk space pg_xlog
  • From: Simon Riggs
• Re: Backup/Restore too slow
  • From: Sebastián Baioni
• Re: Backup/Restore too slow
  • From: Tom Lane
• Re: What you would consider as heavy traffic?
  • From: Rod Taylor
• Re: Backup/Restore too slow
  • From: Rod Taylor
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Arnau
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Ron
• Re: Postgresql Configutation and overflow
  • From: Dave Cramer
• Re: Postgresql Configutation and overflow
  • From: Adam Rich
• Postgresql Configutation and overflow
  • From: fabrix peñuelas
• Postgresql Configutation and overflow
  • From: Fabricio Peñuelas
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Tom Lane
• Re: Advice on selecting good values for work_mem?
  • From: Simon Riggs
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Dave Cramer
• Re: High update activity, PostgreSQL vs BigDBMS
  • From: Shoaib Mir
• High update activity, PostgreSQL vs BigDBMS
  • From: Guy Rouillier
• Re: [GENERAL] Need Help
  • From: Richard Broersma Jr
• Need Help
  • From: JM
• Re: [NOVICE] Partitioning
  • From: Tom Lane
• Re: [NOVICE] Partitioning
  • From: Kevin Hunter
• performance implications of binary placement
  • From: Bob Dusek
• Re: [HACKERS] Questions about planner methods
  • From: Martijn van Oosterhout
• Questions about planner methods
  • From: Kevin Kempter
• [no subject]
  • From: Unknown
• [no subject]
  • From: Unknown
• Re: URGENT: Out of disk space pg_xlog
  • From: Bruce Momjian
• Re: URGENT: Out of disk space pg_xlog
  • From: Jeremy Haile
• Re: URGENT: Out of disk space pg_xlog
  • From: ohp
• What you would consider as heavy traffic?
  • From: oliver@xxxxxxxxxxxx
• Re: URGENT: Out of disk space pg_xlog
  • From: Bruce Momjian
• Re: URGENT: Out of disk space pg_xlog
  • From: Steinar H. Gunderson
• Re: URGENT: Out of disk space pg_xlog
  • From: Alvaro Herrera
• Re: URGENT: Out of disk space pg_xlog
  • From: Tom Lane
• Re: URGENT: Out of disk space pg_xlog
  • From: ohp
• Re: URGENT: Out of disk space pg_xlog
  • From: Tom Lane
• Re: URGENT: Out of disk space pg_xlog
  • From: Kevin Grittner
• Re: URGENT: Out of disk space pg_xlog
  • From: Tom Lane
• Re: URGENT: Out of disk space pg_xlog
  • From: Jeremy Haile
• Re: URGENT: Out of disk space pg_xlog
  • From: Simon Riggs
• Re: URGENT: Out of disk space pg_xlog
  • From: Jeremy Haile
• Re: URGENT: Out of disk space pg_xlog
  • From: Kevin Grittner
• Re: URGENT: Out of disk space pg_xlog
  • From: Simon Riggs
• Re: URGENT: Out of disk space pg_xlog
  • From: Joshua D. Drake
• Re: URGENT: Out of disk space pg_xlog
  • From: Jeremy Haile
• URGENT: Out of disk space pg_xlog
  • From: Jeremy Haile
• Backup/Restore too slow
  • From: Sebastián Baioni
• Re: Question: Clustering & Load Balancing
  • From: Michal Taborsky - Internet Mall
• Re: GROUP BY vs DISTINCT
  • From: Tom Lane
• Question: Clustering & Load Balancing
  • From: CARMODA
• Re: GROUP BY vs DISTINCT
  • From: Peter Childs
• Re: GROUP BY vs DISTINCT
  • From: Steinar H. Gunderson
• Re: max_fsm_pages and check_points
  • From: Ragnar
• GROUP BY vs DISTINCT
  • From: Brian Herlihy
• max_fsm_pages and check_points
  • From: ALVARO ARCILA
• Re: Inner join vs where-clause subquery
  • From: Jeremy Haile
• Re: Inner join vs where-clause subquery
  • From: Jeremy Haile
• Re: Inner join vs where-clause subquery
  • From: Richard Huxton
• Re: Inner join vs where-clause subquery
  • From: Jeremy Haile
• Re: Inner join vs where-clause subquery
  • From: Richard Huxton
• Re: Inner join vs where-clause subquery
  • From: Jeremy Haile
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: Inner join vs where-clause subquery
  • From: Richard Huxton
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Inner join vs where-clause subquery
  • From: Jeremy Haile
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Tom Lane
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Simon Riggs
• Re: Advice on selecting good values for work_mem?
  • From: Bill Moran
• Re: Advice on selecting good values for work_mem?
  • From: Bill Moran
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: opportunity to benchmark a quad core Xeon
  • From: Jeff Frost
• Re: Query plan changing when queried data does not
  • From: Tom Lane
• Query plan changing when queried data does not
  • From: Harry Hehl
• Re: transaction ID wrap limit
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• transaction ID wrap limit
  • From: Sabin Coanda
• Re: Optimizing timestamp queries? Inefficient Overlaps?
  • From: Tom Lane
• Optimizing timestamp queries? Inefficient Overlaps?
  • From: Adam Rich
• Re: Scaling concerns
  • From: Tom Lane
• Re: Scaling concerns
  • From: tsuraan
• Re: Scaling concerns
  • From: Greg Smith
• Re: Scaling concerns
  • From: tsuraan
• Re: Scaling concerns
  • From: tsuraan
• Re: Scaling concerns
  • From: Bill Moran
• Re: File Systems Compared
  • From: Bruno Wolff III
• Re: Scaling concerns
  • From: Luke Lonergan
• Re: Scaling concerns
  • From: Andreas Kostyrka
• Re: Scaling concerns
  • From: Dimitri Fontaine
• Re: partition text/varchar check problem
  • From: Tom Lane
• Re: partition text/varchar check problem
  • From: jamcito
• Re: partition text/varchar check problem
  • From: Ireneusz Pluta
• Re: partition text/varchar check problem -- solved
  • From: jamcito