Postgres Performance Date Index

• Thread Index

• Re: PostgreSQL Parallel Processing !
  • From: sridhar bamandlapally
• pl/pgsql functions outperforming sql ones?
  • From: Carlo Stonebanks
• Re: PostgreSQL Parallel Processing !
  • From: Claudio Freire
• Re: PostgreSQL Parallel Processing !
  • From: Merlin Moncure
• Re: Can lots of small writes badly hamper reads from other tables?
  • From: Jeff Janes
• Re: PostgreSQL Parallel Processing !
  • From: sridhar bamandlapally
• Re: PostgreSQL Parallel Processing !
  • From: Claudio Freire
• Re: PostgreSQL Parallel Processing !
  • From: sridhar bamandlapally
• Re: Cursor fetch performance issue
  • From: Heikki Linnakangas
• Re: Can lots of small writes badly hamper reads from other tables?
  • From: Tomas Vondra
• Re: Can lots of small writes badly hamper reads from other tables?
  • From: Dave Crooke
• Re: Cursor fetch performance issue
  • From: Tony Capobianco
• Re: Cursor fetch performance issue
  • From: Tom Lane
• Re: Cursor fetch performance issue
  • From: Pavel Stehule
• Re: Cursor fetch performance issue
  • From: Pavel Stehule
• Re: Cursor fetch performance issue
  • From: Andy Colson
• Re: Can lots of small writes badly hamper reads from other tables?
  • From: Tomas Vondra
• Re: Can lots of small writes badly hamper reads from other tables?
  • From: Andy Colson
• Re: Cursor fetch performance issue
  • From: Tony Capobianco
• Re: Cursor fetch performance issue
  • From: Pavel Stehule
• Cursor fetch performance issue
  • From: Tony Capobianco
• Can lots of small writes badly hamper reads from other tables?
  • From: Dave Crooke
• Re: spikes in pgbench read-only results
  • From: Tomas Vondra
• Re: Discovering the most searched values for a field
  • From: alexandre - aldeia digital
• Re: Partitioning by status?
  • From: alexandre - aldeia digital
• Re: spikes in pgbench read-only results
  • From: Merlin Moncure
• spikes in pgbench read-only results
  • From: Tomas Vondra
• Re: wal_level=archive gives better performance than minimal - why?
  • From: Tomas Vondra
• Re: when benchmarking insert , can there be caching effects?
  • From: Kevin Grittner
• when benchmarking insert , can there be caching effects?
  • From: Willy-Bas Loos
• Re: wal_level=archive gives better performance than minimal - why?
  • From: Tomas Vondra
• Re: wal_level=archive gives better performance than minimal - why?
  • From: Greg Smith
• Re: auto vacuum, not working?
  • From: Greg Smith
• Re: Discovering the most searched values for a field
  • From: Josh Berkus
• Re: Partitioning by status?
  • From: Josh Berkus
• Discovering the most searched values for a field
  • From: alexandre - aldeia digital
• Re: auto vacuum, not working?
  • From: Kevin Grittner
• Re: auto vacuum, not working?
  • From: Mario Weilguni
• auto vacuum, not working?
  • From: Anibal David Acosta
• Re: Partitioning by status?
  • From: alexandre - aldeia digital
• wal_level=archive gives better performance than minimal - why?
  • From: Tomas Vondra
• Re: Partitioning by status?
  • From: Josh Berkus
• Re: partitioned table: differents plans, slow on some situations
  • From: Matteo Sgalaberni
• Re: partitioned table: differents plans, slow on some situations
  • From: Robert Haas
• Re: Subquery flattening causing sequential scan
  • From: Robert Haas
• Re: Query planner doesn't use index scan on tsvector GIN index if LIMIT is specifiedQuery planner doesn't use index scan on tsvector GIN index if LIMIT is specified
  • From: Jesper Krogh
• Re: pg_upgrade failure "contrib" issue?
  • From: Robert Haas
• Re: Partitioning by status?
  • From: Andreas Kretschmer
• Re: Query planner doesn't use index scan on tsvector GIN index if LIMIT is specifiedQuery planner doesn't use index scan on tsvector GIN index if LIMIT is specified
  • From: Tom Lane
• Partitioning by status?
  • From: Mike Blackwell
• Query planner doesn't use index scan on tsvector GIN index if LIMIT is specified
  • From: darklow
• Query planner doesn't use index scan on tsvector GIN index if LIMIT is specifiedQuery planner doesn't use index scan on tsvector GIN index if LIMIT is specified
  • From: darklow
• Re: Duplicate deletion optimizations
  • From: antoine
• Re: Duplicate deletion optimizations
  • From: Jochen Erwied
• Re: Duplicate deletion optimizations
  • From: Strange, John W
• Re: Duplicate deletion optimizations
  • From: Pierre C
• Re: Duplicate deletion optimizations
  • From: Marc Eberhard
• Re: Duplicate deletion optimizations
  • From: Misa Simic
• Re: Duplicate deletion optimizations
  • From: Jeff Janes
• Re: Duplicate deletion optimizations
  • From: Pierre C
• Re: Duplicate deletion optimizations
  • From: Jochen Erwied
• Re: Duplicate deletion optimizations
  • From: Misa Simic
• Re: Duplicate deletion optimizations
  • From: Marc Mamin
• Re: Duplicate deletion optimizations
  • From: Pierre C
• Re: Duplicate deletion optimizations
  • From: Jochen Erwied
• Re: Duplicate deletion optimizations
  • From: Misa Simic
• Re: Duplicate deletion optimizations
  • From: Marc Eberhard
• Re: Duplicate deletion optimizations
  • From: Samuel Gendler
• Re: Duplicate deletion optimizations
  • From: Marc Eberhard
• Re: Duplicate deletion optimizations
  • From: Samuel Gendler
• Re: Duplicate deletion optimizations
  • From: antoine
• Duplicate deletion optimizations
  • From: antoine
• Re: Slow nested loop execution on larger server
  • From: Strange, John W
• Re: Postgresql Replication Performance
  • From: Aleksej Trofimov
• Re: Postgresql Replication Performance
  • From: Saurabh
• Re: Query performance - normal on 9.0.4, slow from 9.0.5 onwards
  • From: Miguel Silva
• Re: Query performance - normal on 9.0.4, slow from 9.0.5 onwards
  • From: Miguel Silva
• Re: Cost estimate vs. actual - do I care?
  • From: Mark Mielke
• Cost estimate vs. actual - do I care?
  • From: Jay Levitt
• Re: How to clock the time spent for query parsing and planning?
  • From: Igor
• Re: How to clock the time spent for query parsing and planning?
  • From: Pavel Stehule
• Re: Query performance - normal on 9.0.4, slow from 9.0.5 onwards
  • From: Tom Lane
• Re: Query performance - normal on 9.0.4, slow from 9.0.5 onwards
  • From: Merlin Moncure
• Re: Query performance - normal on 9.0.4, slow from 9.0.5 onwards
  • From: Miguel Silva
• Re: Query performance - normal on 9.0.4, slow from 9.0.5 onwards
  • From: Tom Lane
• Query performance - normal on 9.0.4, slow from 9.0.5 onwards
  • From: Miguel Silva
• Re: partitioned table: differents plans, slow on some situations
  • From: Matteo Sgalaberni
• Re: partitioned table: differents plans, slow on some situations
  • From: Marcin Mirosław
• partitioned table: differents plans, slow on some situations
  • From: Matteo Sgalaberni
• Re: parse - bind take more time than execute
  • From: Kevin Grittner
• Re: parse - bind take more time than execute
  • From: MirrorX
• Re: Postgresql Replication Performance
  • From: Aleksej Trofimov
• Re: Postgresql Replication Performance
  • From: Merlin Moncure
• Re: Postgresql Replication Performance
  • From: Claudio Freire
• Re: Postgresql Replication Performance
  • From: Aleksej Trofimov
• Postgresql Replication Performance
  • From: sgupta
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Matteo Beccati
• Re: parse - bind take more time than execute
  • From: Kevin Grittner
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Matteo Beccati
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Claudio Freire
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Matteo Beccati
• Re: Subquery flattening causing sequential scan
  • From: Jim Crate
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Matteo Beccati
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Matteo Beccati
• Re: Subquery flattening causing sequential scan
  • From: Віталій Тимчишин
• Re: Subquery flattening causing sequential scan
  • From: Tom Lane
• Re: Performance costs of various PL languages
  • From: Carlo Stonebanks
• Re: Performance costs of various PL languages
  • From: Andrew Dunstan
• Re: Performance costs of various PL languages
  • From: Merlin Moncure
• Re: Subquery flattening causing sequential scan
  • From: Ondrej Ivanič
• Re: Performance costs of various PL languages
  • From: Pavel Stehule
• Performance costs of various PL languages
  • From: Carlo Stonebanks
• Re: Subquery flattening causing sequential scan
  • From: Tom Lane
• Subquery flattening causing sequential scan
  • From: Jim Crate
• Re: Exploring memory usage
  • From: Scott Marlowe
• Re: Exploring memory usage
  • From: Scott Marlowe
• Re: Exploring memory usage
  • From: Andrew Dunstan
• Re: Exploring memory usage
  • From: Claudio Freire
• Re: Exploring memory usage
  • From: Scott Marlowe
• Re: Exploring memory usage
  • From: Claudio Freire
• Re: parse - bind take more time than execute
  • From: MirrorX
• Re: parse - bind take more time than execute
  • From: Pavel Stehule
• Re: parse - bind take more time than execute
  • From: MirrorX
• Re: parse - bind take more time than execute
  • From: Filip Rembiałkowski
• Re: parse - bind take more time than execute
  • From: MirrorX
• parse - bind take more time than execute
  • From: MirrorX
• Re: How to clock the time spent for query parsing and planning?
  • From: Pavel Stehule
• Exploring memory usage
  • From: Michael Smolsky
• How to clock the time spent for query parsing and planning?
  • From: Igor Schtein
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: Scott Marlowe
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: tuanhoanganh
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: Scott Marlowe
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: tuanhoanganh
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: Scott Marlowe
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: alexandre - aldeia digital
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: Mario Weilguni
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: Satoshi Nagayasu
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: Scott Marlowe
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: tuanhoanganh
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: Scott Marlowe
• Re: Postgresql 9.0.6 Raid 5 or not please help.
  • From: Scott Marlowe
• Postgresql 9.0.6 Raid 5 or not please help.
  • From: tuanhoanganh
• Re: Dramatic change in memory usage with version 9.1
  • From: Havasvölgyi Ottó
• Re: Dramatic change in memory usage with version 9.1
  • From: Rafael Martinez
• Re: OOM-killer issue with a specific query SOLVED
  • From: nabble . 30 . miller_2555
• Re: OOM-killer issue with a specific query 11 of 20)
  • From: nabble . 30 . miller_2555
• Re: Guidance Requested - Bulk Inserting + Queries
  • From: Jeff Janes
• Re: Guidance Requested - Bulk Inserting + Queries
  • From: Benjamin Johnson
• Re: Dramatic change in memory usage with version 9.1
  • From: Havasvölgyi Ottó
• Re: Dramatic change in memory usage with version 9.1
  • From: Kevin Grittner
• Re: Dramatic change in memory usage with version 9.1
  • From: Scott Marlowe
• Re: Dramatic change in memory usage with version 9.1
  • From: Rafael Martinez
• Re: Dramatic change in memory usage with version 9.1
  • From: Rafael Martinez
• Re: Dramatic change in memory usage with version 9.1
  • From: Craig Ringer
• Re: OOM-killer issue with a specific query 9 of 20)
  • From: Tom Lane
• Re: OOM-killer issue with a specific query 9 of 20)
  • From: nabble . 30 . miller_2555
• Re: OOM-killer issue with a specific query
  • From: Scott Marlowe
• Re: Dramatic change in memory usage with version 9.1
  • From: Cédric Villemain
• OOM-killer issue with a specific query
  • From: nabble . 30 . miller_2555
• Re: Dramatic change in memory usage with version 9.1
  • From: Marti Raudsepp
• Re: Dramatic change in memory usage with version 9.1
  • From: ktm@xxxxxxxx
• Dramatic change in memory usage with version 9.1
  • From: Rafael Martinez
• Re: will the planner ever use an index when the condition is <> ?
  • From: Roxanne Reid-Bennett
• Re: will the planner ever use an index when the condition is <> ?
  • From: Marti Raudsepp
• Re: will the planner ever use an index when the condition is <> ?
  • From: Tom Lane
• Re: will the planner ever use an index when the condition is <> ?
  • From: Roxanne Reid-Bennett
• Re: will the planner ever use an index when the condition is <> ?
  • From: Віталій Тимчишин
• Re: will the planner ever use an index when the condition is <> ?
  • From: Filip Rembiałkowski
• will the planner ever use an index when the condition is <> ?
  • From: Roxanne Reid-Bennett
• Re: Slow nested loop execution on larger server
  • From: Scott Marlowe
• Slow nested loop execution on larger server
  • From: Greg Smith
• Re: copy vs. C function
  • From: Jon Nelson
• Re: Is it possible to use index on column for regexp match operator '~'?
  • From: Rural Hunter
• Re: Is it possible to use index on column for regexp match operator '~'?
  • From: Marti Raudsepp
• Re: Slow query after upgrade from 8.2 to 8.4
  • From: Kaloyan Iliev Iliev
• Re: Partitions and joins lead to index lookups on all partitions
  • From: voodooless
• Is it possible to use index on column for regexp match operator '~'?
  • From: Rural Hunter
• Re: copy vs. C function
  • From: Jon Nelson
• Re: copy vs. C function
  • From: Jon Nelson
• Re: copy vs. C function
  • From: Tom Lane
• Re: copy vs. C function
  • From: idc danny
• Re: copy vs. C function
  • From: Jon Nelson
• Re: copy vs. C function
  • From: Kevin Martyn
• Re: Postgres array parser
  • From: Marc Mamin
• Re: Postgres array parser
  • From: Aleksej Trofimov
• Re: Postgres array parser
  • From: Marc Mamin
• Re: copy vs. C function
  • From: idc danny
• Re: copy vs. C function
  • From: Tom Lane
• Re: Slow query after upgrade from 8.2 to 8.4
  • From: Mark Kirkwood
• Re: select distinct uses index scan vs full table scan
  • From: Jon Nelson
• Re: select distinct uses index scan vs full table scan
  • From: Tom Lane
• select distinct uses index scan vs full table scan
  • From: Jon Nelson
• Re: Postgres array parser
  • From: Pavel Stehule
• Re: copy vs. C function
  • From: Jon Nelson
• Re: Postgres array parser
  • From: Aleksej Trofimov
• Re: Postgres array parser
  • From: Pavel Stehule
• Postgres array parser
  • From: Aleksej Trofimov
• Re: copy vs. C function
  • From: Merlin Moncure
• Re: autovacuum, exclude table
  • From: Tom Lane
• Re: autovacuum, exclude table
  • From: Heikki Linnakangas
• Re: autovacuum, exclude table
  • From: Anibal David Acosta
• Re: autovacuum, exclude table
  • From: Craig Ringer
• autovacuum, exclude table
  • From: Anibal David Acosta
• Re: Common slow query reasons - help with a special log
  • From: Tomas Vondra
• Re: copy vs. C function
  • From: Jon Nelson
• Re: copy vs. C function
  • From: Sam Gendler
• Re: copy vs. C function
  • From: Craig Ringer
• copy vs. C function
  • From: Jon Nelson
• Re: Common slow query reasons - help with a special log
  • From: Daniel Cristian Cruz
• Re: Common slow query reasons - help with a special log
  • From: Tomas Vondra
• Re: Common slow query reasons - help with a special log
  • From: Daniel Cristian Cruz
• Re: Common slow query reasons - help with a special log
  • From: Tomas Vondra
• Re: Common slow query reasons - help with a special log
  • From: Andreas Kretschmer
• Common slow query reasons - help with a special log
  • From: Daniel Cristian Cruz
• Re: Slow query after upgrade from 8.2 to 8.4
  • From: Tom Lane
• Re: Slow query after upgrade from 8.2 to 8.4
  • From: Kaloyan Iliev Iliev
• Re: Slow query after upgrade from 8.2 to 8.4
  • From: Tom Lane
• Re: pg_upgrade
  • From: Bruce Momjian
• Re: Slow query after upgrade from 8.2 to 8.4
  • From: Shaun Thomas
• Slow query after upgrade from 8.2 to 8.4
  • From: Kaloyan Iliev Iliev
• Re: Response time increases over time
  • From: Havasvölgyi Ottó
• Re: Response time increases over time
  • From: Bob Lunney
• Re: Response time increases over time
  • From: Havasvölgyi Ottó
• Re: Partitions and joins lead to index lookups on all partitions
  • From: voodooless
• Re: Response time increases over time
  • From: Marti Raudsepp
• Re: Response time increases over time
  • From: Havasvölgyi Ottó
• Re: Response time increases over time
  • From: Aidan Van Dyk
• Re: pg_upgrade failure "contrib" issue?
  • From: Tory M Blue
• Re: Response time increases over time
  • From: Havasvölgyi Ottó
• Re: Partitions and joins lead to index lookups on all partitions
  • From: Ondrej Ivanič
• Re: autovacuum, any log?
  • From: Scott Marlowe
• Re: pg_upgrade
  • From: Tory M Blue
• autovacuum, any log?
  • From: Anibal David Acosta
• Partitions and joins lead to index lookups on all partitions
  • From: Christiaan Willemsen
• Re: Question about VACUUM
  • From: Kevin Grittner
• Re: Intersect/Union X AND/OR
  • From: Marti Raudsepp
• Re: Response time increases over time
  • From: Mario Splivalo
• Re: Different query plans on same servers
  • From: Mario Splivalo
• Re: Response time increases over time
  • From: Havasvölgyi Ottó
• Re: Question about VACUUM
  • From: Josh Berkus
• Re: Response time increases over time
  • From: Josh Berkus
• Re: Different query plans on same servers
  • From: Mario Splivalo
• Re: Different query plans on same servers
  • From: Mario Splivalo
• Re: Different query plans on same servers
  • From: Mario Splivalo
• Response time increases over time
  • From: Havasvölgyi Ottó
• Re: Different query plans on same servers
  • From: Kevin Grittner
• Re: Different query plans on same servers
  • From: Kevin Grittner
• Re: Different query plans on same servers
  • From: Tom Lane
• Different query plans on same servers
  • From: Mario Splivalo
• Re: pg_upgrade
  • From: Tory M Blue
• Re: Question about VACUUM
  • From: Scott Marlowe
• Re: pg_upgrade
  • From: Bruce Momjian
• Re: pg_upgrade
  • From: Bruce Momjian
• Re: pg_upgrade
  • From: Tory M Blue
• Re: Question about VACUUM
  • From: Kevin Grittner
• Re: pg_upgrade
  • From: Tory M Blue
• Re: pg_upgrade
  • From: Bruce Momjian
• Re: Question about VACUUM
  • From: Ernesto Quiñones
• Re: Question about VACUUM
  • From: Scott Marlowe
• Re: Question about VACUUM
  • From: Scott Marlowe
• Re: pg_upgrade
  • From: Tory M Blue
• Re: Question about VACUUM
  • From: Ernesto Quiñones
• Re: pg_upgrade
  • From: Bruce Momjian
• Re: pg_upgrade
  • From: Nicholson, Brad (Toronto, ON, CA)
• Re: pg_upgrade
  • From: Bruce Momjian
• Re: Intersect/Union X AND/OR
  • From: Bruce Momjian
• Re: pg_upgrade
  • From: Nicholson, Brad (Toronto, ON, CA)
• Re: Intersect/Union X AND/OR
  • From: Thiago Godoi
• Re: unlogged tables
  • From: Pierre C
• Re: pg_upgrade
  • From: Bruce Momjian
• Re: pg_upgrade
  • From: Bruce Momjian
• Re: Question about VACUUM
  • From: Scott Marlowe
• Re: pg_upgrade
  • From: Tory M Blue
• Re: Question about VACUUM
  • From: Kevin Grittner
• Re: manually force planner to use of index A vs index B
  • From: MirrorX
• Re: manually force planner to use of index A vs index B
  • From: Tomas Vondra
• manually force planner to use of index A vs index B
  • From: MirrorX
• Re: pg_upgrade
  • From: Bruce Momjian
• Re: pg_upgrade
  • From: Klaus Ita
• Re: Question about VACUUM
  • From: Ernesto Quiñones
• pg_upgrade
  • From: Tory M Blue
• Re: Question about VACUUM
  • From: Scott Marlowe
• Question about VACUUM
  • From: Ernesto Quiñones
• Re: Intersect/Union X AND/OR
  • From: Merlin Moncure
• Re: Intersect/Union X AND/OR
  • From: Bruce Momjian
• Intersect/Union X AND/OR
  • From: Thiago Godoi
• Re: Autovacuum Issue
  • From: Scott Marlowe
• Re: Autovacuum Issue
  • From: Mark Kirkwood
• Re: Guidance Requested - Bulk Inserting + Queries
  • From: Jeff Janes
• Re: vacuum internals and performance affect
  • From: Josh Berkus
• Re: Autovacuum Issue
  • From: Robert Haas
• Re: vacuum internals and performance affect
  • From: MirrorX
• Re: Problems with FTS
  • From: Jesper Krogh
• Re: Guidance Requested - Bulk Inserting + Queries
  • From: Benjamin Johnson
• Re: vacuum internals and performance affect
  • From: MirrorX
• Re: vacuum internals and performance affect
  • From: Josh Berkus
• Re: Problems with FTS
  • From: Robert Haas
• Re: Query planner suggestion, for indexes with similar but not exact ordering.
  • From: Robert Haas
• Re: Guidance Requested - Bulk Inserting + Queries
  • From: Leonardo Francalanci
• Guidance Requested - Bulk Inserting + Queries
  • From: Benjamin Johnson
• vacuum internals and performance affect
  • From: MirrorX
• Re: WAL in RAM
  • From: Marcus Engene
• Re: PostgreSQL 9.1 : why is this query slow?
  • From: Joost Kraaijeveld
• Re: Benchmarking tools, methods
  • From: CSS
• Re: PostgreSQL 9.1 : why is this query slow?
  • From: Tomas Vondra
• Re: PostgreSQL 9.1 : why is this query slow?
  • From: Kevin Grittner
• Re: PostgreSQL 9.1 : why is this query slow?
  • From: Kevin Grittner
• Re: PostgreSQL 9.1 : why is this query slow?
  • From: Joost Kraaijeveld
• Re: PostgreSQL 9.1 : why is this query slow?
  • From: Kevin Grittner
• Re: PostgreSQL 9.1 : why is this query slow?
  • From: Joost Kraaijeveld
• PostgreSQL 9.1 : why is this query slow?
  • From: Joost Kraaijeveld
• Re: Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries
  • From: Maxim Boguk
• Re: Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries
  • From: Craig Ringer
• Re: Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries
  • From: Maxim Boguk
• Re: query uses index but takes too much time?
  • From: Cédric Villemain
• Re: query uses index but takes too much time?
  • From: Aidan Van Dyk
• query uses index but takes too much time?
  • From: MirrorX
• Re: Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries
  • From: Tom Lane
• Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries
  • From: Maxim Boguk
• Re: SSD endurance calculations
  • From: Edgardo Portal
• Re: Seq Scan used instead of Index Scan
  • From: Tom Lane
• Re: Seq Scan used instead of Index Scan
  • From: Mark Kirkwood
• Re: Seq Scan used instead of Index Scan
  • From: Claudio Freire
• Seq Scan used instead of Index Scan
  • From: Gary Warner
• Re: SSD endurance calculations
  • From: Greg Smith
• Re: SSD options, small database, ZFS
  • From: Amitabh Kant
• Re: Autovacuum Issue
  • From: Raghavendra
• Autovacuum Issue
  • From: J Ramesh Kumar
• Re: SSD options, small database, ZFS
  • From: Bruce Momjian
• Re: SSD options, small database, ZFS
  • From: Bruce Momjian
• SSD endurance calculations
  • From: Christiaan Willemsen
• Re: Problems with FTS
  • From: Rauan Maemirov
• Re: external sort performance
  • From: Jeremy Harris
• Re: external sort performance
  • From: Jon Nelson
• Re: external sort performance
  • From: Jeremy Harris
• Re: Benchmarking tools, methods
  • From: Greg Smith
• Re: probably cause (and fix) for floating-point assist faults on itanium
  • From: Greg Matthews
• Re: probably cause (and fix) for floating-point assist faults on itanium
  • From: Tom Lane
• Re: Benchmarking tools, methods
  • From: Scott Marlowe
• Re: SSD options, small database, ZFS
  • From: Amitabh Kant
• Re: SSD options, small database, ZFS
  • From: Tomas Vondra
• Re: SSD options, small database, ZFS
  • From: Scott Marlowe
• Re: probably cause (and fix) for floating-point assist faults on itanium
  • From: Tom Lane
• Re: probably cause (and fix) for floating-point assist faults on itanium
  • From: Claudio Freire
• Re: index usage for min() vs. "order by asc limit 1"
  • From: MirrorX
• Re: Benchmarking tools, methods
  • From: Cédric Villemain
• Re: Benchmarking tools, methods
  • From: Tomas Vondra
• Re: SSD options, small database, ZFS
  • From: Greg Smith
• Benchmarking tools, methods
  • From: CSS
• probably cause (and fix) for floating-point assist faults on itanium
  • From: Greg Matthews
• Re: SSD options, small database, ZFS
  • From: Arjen van der Meijden
• Re: SSD options, small database, ZFS
  • From: CSS
• Re: index usage for min() vs. "order by asc limit 1"
  • From: Ben Chobot
• Re: index usage for min() vs. "order by asc limit 1"
  • From: Steve Atkins
• index usage for min() vs. "order by asc limit 1"
  • From: Ben Chobot
• Re: external sort performance
  • From: Josh Berkus
• Re: external sort performance
  • From: Tom Lane
• Re: external sort performance
  • From: Jon Nelson
• Re: external sort performance
  • From: Jon Nelson
• Re: external sort performance
  • From: Tom Lane
• Re: external sort performance
  • From: Craig James
• Re: external sort performance
  • From: Claudio Freire
• external sort performance
  • From: Jon Nelson
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Claudio Freire
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Tomas Vondra
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Aidan Van Dyk
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Tory M Blue
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Tory M Blue
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Josh Berkus
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Tomas Vondra
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Tory M Blue
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Scott Marlowe
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Scott Marlowe
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Tory M Blue
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Tomas Vondra
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Andy Colson
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Scott Marlowe
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Scott Marlowe
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Tory M Blue
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Tomas Vondra
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Samuel Gendler
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Scott Marlowe
• Re: Performance question 83 GB Table 150 million rows, distinct select
  • From: Alan Hodgson
• Performance question 83 GB Table 150 million rows, distinct select
  • From: Tory M Blue
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Tomas Vondra
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Cody Caughlan
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Tomas Vondra
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Tomas Vondra
• Re: Subquery in a JOIN not getting restricted?
  • From: Jay Levitt
• Re: What's the state of postgresql on ext4 now?
  • From: Greg Smith
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Greg Smith
• Re: What's the state of postgresql on ext4 now?
  • From: Aidan Van Dyk
• Re: What's the state of postgresql on ext4 now?
  • From: Scott Marlowe
• Re: What's the state of postgresql on ext4 now?
  • From: Greg Smith
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Tomas Vondra
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Cody Caughlan
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Tomas Vondra
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Tomas Vondra
• Re: What's the state of postgresql on ext4 now?
  • From: Scott Marlowe
• Re: unlogged tables
  • From: Josh Berkus
• Re: What's the state of postgresql on ext4 now?
  • From: Josh Berkus
• Re: avoiding seq scans when two columns are very correlated
  • From: Ruslan Zakirov
• Re: Large number of short lived connections - could a connection pool help?
  • From: Mario Weilguni
• Re: What's the state of postgresql on ext4 now?
  • From: Maciek Sakrejda
• What's the state of postgresql on ext4 now?
  • From: Alexandru
• Re: avoiding seq scans when two columns are very correlated
  • From: Stuart Bishop
• Re: Large number of short lived connections - could a connection pool help?
  • From: Ben Chobot
• Re: Large number of short lived connections - could a connection pool help?
  • From: Cody Caughlan
• Large number of short lived connections - could a connection pool help?
  • From: Cody Caughlan
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Cody Caughlan
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Tomas Vondra
• Query planner suggestion, for indexes with similar but not exact ordering.
  • From: Andrew Barnham
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Cody Caughlan
• Re: Using incrond for archiving
  • From: Shaun Thomas
• Re: Using incrond for archiving
  • From: Kevin Grittner
• Re: Using incrond for archiving
  • From: Shaun Thomas
• Re: Slow queries / commits, mis-configuration or hardware issues?
  • From: Tomas Vondra
• Slow queries / commits, mis-configuration or hardware issues?
  • From: Cody Caughlan
• Re: unlogged tables
  • From: Kevin Grittner
• Re: unlogged tables
  • From: Anibal David Acosta
• Re: unlogged tables
  • From: Kevin Grittner
• Re: unlogged tables
  • From: Anibal David Acosta
• Re: unlogged tables
  • From: Sergey Konoplev
• Re: unlogged tables
  • From: Richard Huxton
• Re: unlogged tables
  • From: Sergey Konoplev
• Re: unlogged tables
  • From: Richard Huxton
• Re: unlogged tables
  • From: Sergey Konoplev
• Re: : bg_writer overloaded ?
  • From: Venkat Balaji
• Re: Trying to understand Stats/Query planner issue
  • From: Tom Lane
• Re: Heavy contgnous load
  • From: Pavel Stehule
• Re: Subquery in a JOIN not getting restricted?
  • From: Gavin Flower
• Re: Heavy contgnous load
  • From: kzsolt
• Trying to understand Stats/Query planner issue
  • From: Strange, John W
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Lucas Mocellin
• Re: WAL partition filling up after high WAL activity
  • From: Greg Smith
• Using incrond for archiving
  • From: Shaun Thomas
• Re: unlogged tables
  • From: Stephen Frost
• unlogged tables
  • From: Anibal David Acosta
• Re: where clause + function, execution order
  • From: Richard Huxton
• Re: avoiding seq scans when two columns are very correlated
  • From: Ruslan Zakirov
• Re: where clause + function, execution order
  • From: Sorin Dudui
• Re: where clause + function, execution order
  • From: Tom Lane
• Re: where clause + function, execution order
  • From: Richard Huxton
• Re: where clause + function, execution order
  • From: Julius Tuskenis
• where clause + function, execution order
  • From: Sorin Dudui
• Re: avoiding seq scans when two columns are very correlated
  • From: Tom Lane
• avoiding seq scans when two columns are very correlated
  • From: Ruslan Zakirov
• Re: WAL partition filling up after high WAL activity
  • From: Rafael Martinez
• Re: Heavy contgnous load
  • From: kzsolt
• Re: Subquery in a JOIN not getting restricted?
  • From: Jay Levitt
• Re: Subquery in a JOIN not getting restricted?
  • From: Tom Lane
• Re: IMMUTABLE STABLE functions, daily updates
  • From: Craig Ringer
• Re: Subquery in a JOIN not getting restricted?
  • From: Jay Levitt
• Re: IMMUTABLE STABLE functions, daily updates
  • From: Thom Brown
• IMMUTABLE STABLE functions, daily updates
  • From: Sorin Dudui
• Re: Subquery in a JOIN not getting restricted?
  • From: Jay Levitt
• Re: Subquery in a JOIN not getting restricted?
  • From: Kevin Grittner
• Re: Subquery in a JOIN not getting restricted?
  • From: Merlin Moncure
• Re: WAL partition filling up after high WAL activity
  • From: Greg Smith
• Re: Subquery in a JOIN not getting restricted?
  • From: Kevin Grittner
• Re: : bg_writer overloaded ?
  • From: Scott Marlowe
• : bg_writer overloaded ?
  • From: Venkat Balaji
• Re: STRICT SQL functions never inline
  • From: Tom Lane
• Re: STRICT SQL functions never inline
  • From: Andres Freund
• STRICT SQL functions never inline
  • From: Josh Berkus
• Re: SSL encryption makes bytea transfer slow
  • From: Albe Laurenz
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Mario Weilguni
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Tomas Vondra
• Re: SSL encryption makes bytea transfer slow
  • From: Albe Laurenz
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Mohamed Hashim
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Tomas Vondra
• Re: SSL encryption makes bytea transfer slow
  • From: Marti Raudsepp
• Re: SSL encryption makes bytea transfer slow
  • From: Albe Laurenz
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Sam Gendler
• Re: Error while vacuuming
  • From: Samuel Gendler
• Re: Error while vacuuming
  • From: Bhakti Ghatkar
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Mohamed Hashim
• Re: Subquery in a JOIN not getting restricted?
  • From: Jay Levitt
• Re: Subquery in a JOIN not getting restricted?
  • From: Jay Levitt
• Re: Subquery in a JOIN not getting restricted?
  • From: Kevin Grittner
• WAL partition filling up after high WAL activity
  • From: Richard Yen
• Re: Subquery in a JOIN not getting restricted?
  • From: Kevin Grittner
• Re: Subquery in a JOIN not getting restricted?
  • From: Tom Lane
• Subquery in a JOIN not getting restricted?
  • From: Jay Levitt
• Re: Blocking excessively in FOR UPDATE
  • From: Claudio Freire
• Re: Predicates not getting pushed into SQL function?
  • From: Jay Levitt
• Re: Predicates not getting pushed into SQL function?
  • From: Jay Levitt
• Re: PostgreSQL perform poorly on VMware ESXi
  • From: Ivan Voras
• Re: PostgreSQL perform poorly on VMware ESXi
  • From: ktm@xxxxxxxx
• Re: PostgreSQL perform poorly on VMware ESXi
  • From: Tomas Vondra
• PostgreSQL perform poorly on VMware ESXi
  • From: Lucas Mocellin
• Re: SSL encryption makes bytea transfer slow
  • From: Heikki Linnakangas
• Re: Blocking excessively in FOR UPDATE
  • From: Claudio Freire
• Re: Blocking excessively in FOR UPDATE
  • From: Shaun Thomas
• Re: Blocking excessively in FOR UPDATE
  • From: Robert Haas
• Re: Strange query plan
  • From: Robert Haas
• Re: Blocking excessively in FOR UPDATE
  • From: Claudio Freire
• Re: Blocking excessively in FOR UPDATE
  • From: Shaun Thomas
• Re: Blocking excessively in FOR UPDATE
  • From: Claudio Freire
• Re: Blocking excessively in FOR UPDATE
  • From: Kevin Grittner
• Re: Blocking excessively in FOR UPDATE
  • From: Claudio Freire
• Re: Blocking excessively in FOR UPDATE
  • From: Kevin Grittner
• Re: Strange query plan
  • From: Sorbara, Giorgio (CIOK)
• Re: Blocking excessively in FOR UPDATE
  • From: Robert Haas
• Re: Blocking excessively in FOR UPDATE
  • From: Claudio Freire
• Re: Strange query plan
  • From: Robert Haas
• Re: Error while vacuuming
  • From: Tom Lane
• Re: Error while vacuuming
  • From: Guillaume Cottenceau
• Error while vacuuming
  • From: Bhakti Ghatkar
• Re: SSL encryption makes bytea transfer slow
  • From: Albe Laurenz
• Re: Blocking excessively in FOR UPDATE
  • From: Tom Lane
• Re: function slower than the same code in an sql file
  • From: CS DBA
• Re: Predicates not getting pushed into SQL function?
  • From: Tom Lane
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Mario Weilguni
• Re: Blocking excessively in FOR UPDATE
  • From: Claudio Freire
• Re: Blocking excessively in FOR UPDATE
  • From: Claudio Freire
• Re: Predicates not getting pushed into SQL function?
  • From: Jay Levitt
• Re: Blocking excessively in FOR UPDATE
  • From: Tom Lane
• Re: Predicates not getting pushed into SQL function?
  • From: Tom Lane
• Re: Optimization required for multiple insertions in PostgreSQL
  • From: Kevin Grittner
• Re: Blocking excessively in FOR UPDATE
  • From: Claudio Freire
• Blocking excessively in FOR UPDATE
  • From: Claudio Freire
• Predicates not getting pushed into SQL function?
  • From: Jay Levitt
• Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Gavin Flower
• Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Justin Pitts
• Re: SSL encryption makes bytea transfer slow
  • From: Marti Raudsepp
• Re: Optimization required for multiple insertions in PostgreSQL
  • From: Tomas Vondra
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Tomas Vondra
• Re: Optimization required for multiple insertions in PostgreSQL
  • From: Kevin Grittner
• Re: Intel 710 pgbench write latencies
  • From: Yeb Havinga
• Optimization required for multiple insertions in PostgreSQL
  • From: siva palanisamy
• Re: function slower than the same code in an sql file
  • From: Robert Haas
• Re: Query running a lot faster with enable_nestloop=false
  • From: Robert Haas
• Re: function slower than the same code in an sql file
  • From: Rodrigo Gonzalez
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Mario Weilguni
• Re: SSL encryption makes bytea transfer slow
  • From: ktm@xxxxxxxx
• Re: SSL encryption makes bytea transfer slow
  • From: Albe Laurenz
• Re: function slower than the same code in an sql file
  • From: Robert Haas
• Re: Intel 710 pgbench write latencies
  • From: Yeb Havinga
• Re: Intel 710 pgbench write latencies
  • From: Shaun Thomas
• Re: Poor performance on a simple join
  • From: Shaun Thomas
• Re: Intel 710 pgbench write latencies
  • From: Merlin Moncure
• Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Igor Neyman
• Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Craig Ringer
• Re: Intel 710 pgbench write latencies
  • From: Yeb Havinga
• Re: Intel 710 pgbench write latencies
  • From: Andy
• Re: Poor performance on a simple join
  • From: Scott Marlowe
• Re: two table join just not fast enough.
  • From: Mark Kirkwood
• Re: two table join just not fast enough.
  • From: Brian Fehrle
• Re: two table join just not fast enough.
  • From: Tom Lane
• Re: Poor performance on a simple join
  • From: CS DBA
• Re: Intel 710 pgbench write latencies
  • From: Merlin Moncure
• Re: Poor performance on a simple join
  • From: Scott Marlowe
• Re: Intel 710 pgbench write latencies
  • From: Yeb Havinga
• Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Igor Neyman
• Poor performance on a simple join
  • From: CS DBA
• two table join just not fast enough.
  • From: Brian Fehrle
• Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Craig James
• Re: Intel 710 pgbench write latencies
  • From: Merlin Moncure
• Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Claudio Freire
• Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Andres Freund
• Re: Intel 710 pgbench write latencies
  • From: David Boreham
• Re: Intel 710 pgbench write latencies
  • From: Yeb Havinga
• Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Robert Haas
• Re: Intel 710 pgbench write latencies
  • From: Magnus Hagander
• Re: Intel 710 pgbench write latencies
  • From: Yeb Havinga
• Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Tom Lane
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Tom Lane
• Re: Intel 710 pgbench write latencies
  • From: Merlin Moncure
• Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
  • From: Jay Levitt
• Re: Intel 710 pgbench write latencies
  • From: Kevin Grittner
• Intel 710 pgbench write latencies
  • From: Yeb Havinga
• Re: procedure takes much more time than its query statement
  • From: Sabin Coanda
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Mohamed Hashim
• Re: procedure takes much more time than its query statement
  • From: Craig Ringer
• Re: procedure takes much more time than its query statement
  • From: Dave Crooke
• procedure takes much more time than its query statement
  • From: Sabin Coanda
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Tom Lane
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Tomas Vondra
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: ktm@xxxxxxxx
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Marcus Engene
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Mohamed Hashim
• Re: does update of column with no relation imply a relation check of other column?
  • From: Tom Lane
• Re: Composite keys
  • From: Tom Lane
• Re: SSL encryption makes bytea transfer slow
  • From: Merlin Moncure
• Re: Composite keys
  • From: Robert Haas
• Re: Composite keys
  • From: Claudio Freire
• Re: Composite keys
  • From: Robert Haas
• Re: does update of column with no relation imply a relation check of other column?
  • From: Robert Haas
• Re: Composite keys
  • From: Claudio Freire
• Re: Anti join miscalculates row number?
  • From: Jens Reufsteck
• Re: Composite keys
  • From: Robert Haas
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Sören Meyer-Eppler
• Re: SSL encryption makes bytea transfer slow
  • From: Albe Laurenz
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Tom Lane
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Sören Meyer-Eppler
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Sören Meyer-Eppler
• Re: Strange query plan
  • From: Sorbara, Giorgio (CIOK)
• Re: WAL in RAM
  • From: Scott Marlowe
• Re: WAL in RAM
  • From: Marcus Engene
• Re: application of KNN code to US zipcode searches?
  • From: Mark Stosberg
• Re: Bad plan by Planner (Already resolved?)
  • From: Robins Tharakan
• Re: SSL encryption makes bytea transfer slow
  • From: Heikki Linnakangas
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Mohamed Hashim
• Re: backups blocking everything
  • From: Samuel Gendler
• Re: backups blocking everything
  • From: Merlin Moncure
• Re: WAL in RAM
  • From: David Boreham
• Re: WAL in RAM
  • From: Claudio Freire
• Re: WAL in RAM
  • From: Tomas Vondra
• Re: WAL in RAM
  • From: Tomas Vondra
• Re: should i expected performance degradation over time
  • From: Robert Haas
• Re: WAL in RAM
  • From: Merlin Moncure
• Re: WAL in RAM
  • From: Tomas Vondra
• Re: Strange query plan
  • From: Tomas Vondra
• Strange query plan
  • From: Sorbara, Giorgio (CIOK)
• Re: WAL in RAM
  • From: Merlin Moncure
• Re: [GENERAL] Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Alban Hertroys
• Re: WAL in RAM
  • From: Kevin Grittner
• WAL in RAM
  • From: Marcus Engene
• Re: function slower than the same code in an sql file
  • From: CS DBA
• Re: Choosing between Intel 320, Intel 510 or OCZ Vertex 3 SSD for db server
  • From: David Boreham
• SSL encryption makes bytea transfer slow
  • From: Albe Laurenz
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Mohamed Hashim
• Re: Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Gregg Jaskiewicz
• Performance Problem with postgresql 9.03, 8GB RAM,Quadcore Processor Server--Need help!!!!!!!
  • From: Mohamed Hashim
• Re: Choosing between Intel 320, Intel 510 or OCZ Vertex 3 SSD for db server
  • From: Amitabh Kant
• Re: Usage of pg_stat_database
  • From: Amitabh Kant
• Re: Usage of pg_stat_database
  • From: Jeff Davis
• Re: function slower than the same code in an sql file
  • From: Pavel Stehule
• Re: function slower than the same code in an sql file
  • From: Tom Lane
• function slower than the same code in an sql file
  • From: CS DBA
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Josh Berkus
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Tom Lane
• Re: backups blocking everything
  • From: Samuel Gendler
• Re: Performance problem with a table with 38928077 record
  • From: Tom Lane
• Re: backups blocking everything
  • From: Nicholson, Brad (Toronto, ON, CA)
• Re: Performance problem with a table with 38928077 record
  • From: Shaun Thomas
• Re: backups blocking everything
  • From: Samuel Gendler
• Re: Performance problem with a table with 38928077 record
  • From: Robert Haas
• Re: Shortcutting too-large offsets?
  • From: Robert Haas
• Re: backups blocking everything
  • From: Merlin Moncure
• backups blocking everything
  • From: Samuel Gendler
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Claudio Freire
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Sören Meyer-Eppler
• Re: PostgreSQL 9.0.4 blocking in lseek?
  • From: Gregg Jaskiewicz
• PostgreSQL 9.0.4 blocking in lseek?
  • From: Sören Meyer-Eppler
• Re: Anti join miscalculates row number?
  • From: Julius Tuskenis
• Re: Bad plan by Planner (Already resolved?)
  • From: Tom Lane
• Re: Anti join miscalculates row number?
  • From: Tom Lane
• Re: Slow cursor
  • From: Andres Freund
• Re: Slow cursor
  • From: Cezariusz Marek
• Re: CTE vs Subquery
  • From: Linos
• Re: Slow cursor
  • From: Gregg Jaskiewicz
• Slow cursor
  • From: Cezariusz Marek
• Re: CTE vs Subquery
  • From: Merlin Moncure
• Anti join miscalculates row number?
  • From: Jens Reufsteck
• Re: CTE vs Subquery
  • From: Linos
• Re: how to use explain analyze
  • From: Julius Tuskenis
• how to use explain analyze
  • From: alan
• Re: CTE vs Subquery
  • From: Merlin Moncure
• Re: CTE vs Subquery
  • From: Linos
• Re: CTE vs Subquery
  • From: Tom Lane
• CTE vs Subquery
  • From: Linos
• Re: Choosing between Intel 320, Intel 510 or OCZ Vertex 3 SSD for db server
  • From: David Boreham
• Re: Choosing between Intel 320, Intel 510 or OCZ Vertex 3 SSD for db server
  • From: Claudio Freire
• Re: Bad plan by Planner (Already resolved?)
  • From: Robins Tharakan