Postgres Performance Date Index

• Thread Index

• Re: Performance under contention
  • From: Ivan Voras
• Re: Performance under contention
  • From: Kevin Grittner
• Re: Slow SELECT on small table
  • From: Kevin Grittner
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Query Performance SQL Server vs. Postgresql
  • From: Samuel Gendler
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Performance under contention
  • From: Omar Kilani
• Slow SELECT on small table
  • From: Martin Boese
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Re: autovacuum blocks the operations of other manual vacuum
  • From: kuopo
• Re: autovacuum blocks the operations of other manual vacuum
  • From: kuopo
• Re: Performance under contention
  • From: Jignesh Shah
• Re: Performance under contention
  • From: Ivan Voras
• Re: Performance under contention
  • From: Kevin Grittner
• Performance under contention
  • From: Ivan Voras
• Re: Query Performance SQL Server vs. Postgresql
  • From: Robert Haas
• Re: Query Performance SQL Server vs. Postgresql
  • From: Tom Lane
• Re: autovacuum blocks the operations of other manual vacuum
  • From: Alvaro Herrera
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Should changing offset in LIMIT change query plan (at all/so early)?
  • From: Kevin Grittner
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Query Performance SQL Server vs. Postgresql
  • From: Kevin Grittner
• Re: Query Performance SQL Server vs. Postgresql
  • From: Pavel Stehule
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Query Performance SQL Server vs. Postgresql
  • From: Pavel Stehule
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Should changing offset in LIMIT change query plan (at all/so early)?
  • From: goran
• Re: Query Performance SQL Server vs. Postgresql
  • From: Pavel Stehule
• Re: best db schema for time series data?
  • From: Bob Lunney
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Dimitri
• Re: autovacuum blocks the operations of other manual vacuum
  • From: tv
• Re: autovacuum blocks the operations of other manual vacuum
  • From: Alvaro Herrera
• Re: best db schema for time series data?
  • From: Robert Klemme
• Re: best db schema for time series data?
  • From: Chris Browne
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Jignesh Shah
• Re: best db schema for time series data?
  • From: Louis-David Mitterrand
• Re: best db schema for time series data?
  • From: Louis-David Mitterrand
• Re: autovacuum blocks the operations of other manual vacuum
  • From: kuopo
• Re: Query Performance SQL Server vs. Postgresql
  • From: Kevin Grittner
• Re: Low disk performance?
  • From: tv
• Low disk performance?
  • From: Martin Chlupac
• executor stats / page reclaims
  • From: Uwe Bartels
• Re: Query Performance SQL Server vs. Postgresql
  • From: Pavel Stehule
• Re: Anyone seen this kind of lock pileup?
  • From: Tom Lane
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Greg Smith
• Re: Anyone seen this kind of lock pileup?
  • From: Josh Berkus
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Ivan Voras
• Re: Query Performance SQL Server vs. Postgresql
  • From: Tom Lane
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Scott Carey
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Eric Comeau
• Re: Anyone seen this kind of lock pileup?
  • From: Ivan Voras
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Greg Smith
• Re: Query Performance SQL Server vs. Postgresql
  • From: Mladen Gogala
• Re: Anyone seen this kind of lock pileup?
  • From: Josh Berkus
• Re: Anyone seen this kind of lock pileup?
  • From: Tom Lane
• Re: Query Performance SQL Server vs. Postgresql
  • From: Rich
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Jon Nelson
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Greg Smith
• Re: Query Performance SQL Server vs. Postgresql
  • From: Tomas Vondra
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Scott Carey
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Scott Carey
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Scott Carey
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Scott Carey
• Anyone seen this kind of lock pileup?
  • From: Josh Berkus
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Merlin Moncure
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Ivan Voras
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Lutz Steinborn
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Digimer
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: J. Roeleveld
• How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Eric Comeau
• Re: Query Performance SQL Server vs. Postgresql
  • From: Pavel Stehule
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Robert Haas
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Tom Lane
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Tom Lane
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Josh Berkus
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Andres Freund
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Tom Lane
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Andres Freund
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Tom Lane
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Andres Freund
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Mladen Gogala
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Marti Raudsepp
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Tom Lane
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Josh Berkus
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Robert Haas
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Greg Smith
• Re: best db schema for time series data?
  • From: Chris Browne
• Re: best db schema for time series data?
  • From: Harald Fuchs
• Re: autovacuum blocks the operations of other manual vacuum
  • From: Alvaro Herrera
• Re: best db schema for time series data?
  • From: Jayadevan M
• Re: best db schema for time series data?
  • From: Louis-David Mitterrand
• Re: best db schema for time series data?
  • From: Arjen van der Meijden
• Re: best db schema for time series data?
  • From: Pavel Stehule
• Re: best db schema for time series data?
  • From: Louis-David Mitterrand
• Re: best db schema for time series data?
  • From: Pavel Stehule
• best db schema for time series data?
  • From: Louis-David Mitterrand
• Re:
  • From: Pavel Stehule
• Re:
  • From: Mark Kirkwood
• Re:
  • From: Jayadevan M
• [no subject]
  • From: Humair Mohammed
• Re: Difference between explain analyze and real execution time
  • From: Artur Zając
• Re: Difference between explain analyze and real execution time
  • From: Tom Lane
• Re: Difference between explain analyze and real execution time
  • From: Artur Zając
• Re: Difference between explain analyze and real execution time
  • From: Robert Haas
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Robert Haas
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Andy Colson
• Re: Difference between explain analyze and real execution time
  • From: Tobias Brox
• Re: Difference between explain analyze and real execution time
  • From: Artur Zając
• Re: Difference between explain analyze and real execution time
  • From: Tom Lane
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Robert Haas
• Difference between explain analyze and real execution time
  • From: Artur Zając
• Re: MVCC performance issue
  • From: Mladen Gogala
• Re: Why dose the planner select one bad scan plan.
  • From: Robert Haas
• Re: temporary tables, indexes, and query plans
  • From: Tom Lane
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Marti Raudsepp
• Re: MVCC performance issue
  • From: Marti Raudsepp
• Re: MVCC performance issue
  • From: Marti Raudsepp
• Re: temporary tables, indexes, and query plans
  • From: Robert Haas
• Re: temporary tables, indexes, and query plans
  • From: Tom Lane
• Re: temporary tables, indexes, and query plans
  • From: Robert Haas
• Re: anti-join chosen even when slower than old plan
  • From: Robert Haas
• Re: MVCC performance issue
  • From: Craig Ringer
• Re: MVCC performance issue
  • From: Mladen Gogala
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Tom Lane
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Marti Raudsepp
• Re: temporary tables, indexes, and query plans
  • From: Tom Lane
• Re: temporary tables, indexes, and query plans
  • From: Jon Nelson
• Re: anti-join chosen even when slower than old plan
  • From: bricklen
• Re: temporary tables, indexes, and query plans
  • From: Tom Lane
• Re: do temporary tables have hint bits?
  • From: Tom Lane
• do temporary tables have hint bits?
  • From: Jon Nelson
• Re: anti-join chosen even when slower than old plan
  • From: Marc Mamin
• Re: MVCC performance issue
  • From: Rich
• Re: MVCC performance issue
  • From: Craig Ringer
• Re: anti-join chosen even when slower than old plan
  • From: Cédric Villemain
• Re: temporary tables, indexes, and query plans
  • From: Jon Nelson
• autovacuum blocks the operations of other manual vacuum
  • From: kuopo
• MVCC performance issue
  • From: Kyriacos Kyriacou
• Re: Why dose the planner select one bad scan plan.
  • From: 静安寺
• Re: questions regarding shared_buffers behavior
  • From: Robert Haas
• Re: anti-join chosen even when slower than old plan
  • From: Robert Haas
• Re: MVCC performance issue
  • From: Scott Carey
• Re: MVCC performance issue
  • From: Scott Carey
• Re: MVCC performance issue
  • From: Scott Marlowe
• Re: MVCC performance issue
  • From: Scott Marlowe
• Re: MVCC performance issue
  • From: Scott Marlowe
• Re: MVCC performance issue
  • From: Kyriacos Kyriacou
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: MVCC performance issue
  • From: Kyriacos Kyriacou
• Re: anti-join chosen even when slower than old plan
  • From: Robert Haas
• Re: MVCC performance issue
  • From: Tom Lane
• Re: MVCC performance issue
  • From: Ben Chobot
• Re: MVCC performance issue
  • From: Thom Brown
• Re: MVCC performance issue
  • From: Kenneth Marshall
• Re: MVCC performance issue
  • From: Andy Colson
• Re: MVCC performance issue
  • From: Kyriacos Kyriacou
• Re: MVCC performance issue
  • From: Kyriacos Kyriacou
• Re: postmaster consuming /lots/ of memory with hash aggregate. why?
  • From: Pavel Stehule
• Re: MVCC performance issue
  • From: Vitalii Tymchyshyn
• Re: MVCC performance issue
  • From: Kenneth Marshall
• Re: MVCC performance issue
  • From: bricklen
• Re: postmaster consuming /lots/ of memory with hash aggregate. why?
  • From: Jon Nelson
• Re: MVCC performance issue
  • From: Thom Brown
• Re: MVCC performance issue
  • From: Kenneth Marshall
• MVCC performance issue
  • From: Kyriacos Kyriacou
• Re: anti-join chosen even when slower than old plan
  • From: Cédric Villemain
• Re: anti-join chosen even when slower than old plan
  • From: Vitalii Tymchyshyn
• Re: anti-join chosen even when slower than old plan
  • From: Cédric Villemain
• Re: anti-join chosen even when slower than old plan
  • From: Vitalii Tymchyshyn
• Re: anti-join chosen even when slower than old plan
  • From: Cédric Villemain
• Re: anti-join chosen even when slower than old plan
  • From: Cédric Villemain
• Re: postmaster consuming /lots/ of memory with hash aggregate. why?
  • From: Pavel Stehule
• Re: postmaster consuming /lots/ of memory with hash aggregate. why?
  • From: Jon Nelson
• Re: postmaster consuming /lots/ of memory with hash aggregate. why?
  • From: Pavel Stehule
• Re: postmaster consuming /lots/ of memory with hash aggregate. why?
  • From: Jon Nelson
• Re: equivalent queries lead to different query plans for self-joins with group by?
  • From: Ben
• Re: equivalent queries lead to different query plans for self-joins with group by?
  • From: Tom Lane
• equivalent queries lead to different query plans for self-joins with group by?
  • From: Ben
• Re: anti-join chosen even when slower than old plan
  • From: Kenneth Marshall
• Re: anti-join chosen even when slower than old plan
  • From: gnuoytr
• Re: anti-join chosen even when slower than old plan
  • From: Robert Haas
• Re: anti-join chosen even when slower than old plan
  • From: Jon Nelson
• Re: anti-join chosen even when slower than old plan
  • From: Andres Freund
• Re: CREATE INDEX as bottleneck
  • From: Marc Mamin
• Re: anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Re: anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Re: anti-join chosen even when slower than old plan
  • From: Robert Haas
• Re: anti-join chosen even when slower than old plan
  • From: Robert Haas
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: CREATE INDEX as bottleneck
  • From: Alex Hunsaker
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: anti-join chosen even when slower than old plan
  • From: Mladen Gogala
• Re: anti-join chosen even when slower than old plan
  • From: Robert Haas
• Re: anti-join chosen even when slower than old plan
  • From: Craig James
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: anti-join chosen even when slower than old plan
  • From: Mladen Gogala
• Re: anti-join chosen even when slower than old plan
  • From: Bob Lunney
• Re: anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Re: anti-join chosen even when slower than old plan
  • From: Kenneth Marshall
• Re: anti-join chosen even when slower than old plan
  • From: Mladen Gogala
• Re: CREATE INDEX as bottleneck
  • From: Kenneth Marshall
• Re: anti-join chosen even when slower than old plan
  • From: Kenneth Marshall
• CREATE INDEX as bottleneck
  • From: Marc Mamin
• Re: Why dose the planner select one bad scan plan.
  • From: tv
• Re: anti-join chosen even when slower than old plan
  • From: Віталій Тимчишин
• Re: anti-join chosen even when slower than old plan
  • From: Mladen Gogala
• Re: anti-join chosen even when slower than old plan
  • From: Robert Haas
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Re: anti-join chosen even when slower than old plan
  • From: Robert Haas
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Re: Why dose the planner select one bad scan plan.
  • From: tv
• Re: anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Why dose the planner select one bad scan plan.
  • From: 静安寺
• Re: Array interface
  • From: Mark Kirkwood
• Re: Array interface
  • From: Mark Kirkwood
• Re: anti-join chosen even when slower than old plan
  • From: Grzegorz Jaśkiewicz
• Re: Huge overestimation in rows expected results in bad plan
  • From: bricklen
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: Huge overestimation in rows expected results in bad plan
  • From: Tom Lane
• Re: Huge overestimation in rows expected results in bad plan
  • From: bricklen
• Re: Huge overestimation in rows expected results in bad plan
  • From: Tom Lane
• Re: anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Re: anti-join chosen even when slower than old plan
  • From: Tom Lane
• Re: anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Re: Huge overestimation in rows expected results in bad plan
  • From: bricklen
• Re: Huge overestimation in rows expected results in bad plan
  • From: Andy Colson
• Huge overestimation in rows expected results in bad plan
  • From: bricklen
• anti-join chosen even when slower than old plan
  • From: Kevin Grittner
• Re: out of memory problem
  • From: Bob Lunney
• Re: out of memory problem
  • From: Tom Lane
• out of memory problem
  • From: Till Kirchner
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Andres Freund
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Greg Smith
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Klaus Ita
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Dimitri Fontaine
• Re: Select * is very slow
  • From: Justin Pitts
• Re: Select * is very slow
  • From: Pierre C
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Tom Lane
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Scott Carey
• Re: Select * is very slow
  • From: Kevin Grittner
• Re: Select * is very slow
  • From: Thomas Kellerer
• Re: Select * is very slow
  • From: Kevin Grittner
• Re: Select * is very slow
  • From: Kevin Grittner
• Re: Select * is very slow
  • From: Thom Brown
• Re: Select * is very slow
  • From: Pavel Stehule
• Select * is very slow
  • From: shaiju.ck
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Lello, Nick
• Array interface
  • From: Mladen Gogala
• Help with bulk read performance
  • From: Dan Schaffer
• Array interface
  • From: Mladen Gogala
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Marti Raudsepp
• Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
  • From: Francisco Reyes
• Re: questions regarding shared_buffers behavior
  • From: Cédric Villemain
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Marti Raudsepp
• Re: questions regarding shared_buffers behavior
  • From: Mark Rostron
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Greg Smith
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Andres Freund
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Greg Smith
• Re: questions regarding shared_buffers behavior
  • From: Greg Smith
• questions regarding shared_buffers behavior
  • From: Mark Rostron
• Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
  • From: Robert Haas
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Craig Ringer
• Re: postmaster consuming /lots/ of memory with hash aggregate. why?
  • From: Jon Nelson
• Re: postmaster consuming /lots/ of memory with hash aggregate. why?
  • From: Pierre C
• postmaster consuming /lots/ of memory with hash aggregate. why?
  • From: Jon Nelson
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Pierre C
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Marti Raudsepp
• Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
  • From: Scott Carey
• Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
  • From: Josh Berkus
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Josh Berkus
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Greg Smith
• Re: Simple (hopefully) throughput question?
  • From: Samuel Gendler
• Re: Simple (hopefully) throughput question?
  • From: Samuel Gendler
• Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
  • From: Greg Smith
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Andres Freund
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Marti Raudsepp
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Greg Smith
• Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
  • From: Scott Marlowe
• Re: Bufer cache replacement LRU algorithm?
  • From: Greg Smith
• Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
  • From: Andres Freund
• Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
  • From: Josh Berkus
• Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
  • From: Scott Marlowe
• Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
  • From: Josh Berkus
• Major Linux performance regression; shouldn't we be worried about RHEL6?
  • From: Josh Berkus
• Re: Simple (hopefully) throughput question?
  • From: Robert Klemme
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Mladen Gogala
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Chris Browne
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Devrim GÜNDÜZ
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Jon Nelson
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Guillaume Cottenceau
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Guillaume Cottenceau
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Marti Raudsepp
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Thom Brown
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Marti Raudsepp
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: A B
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: A B
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Craig Ringer
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: A B
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Szymon Guz
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Guillaume Cottenceau
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Thom Brown
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Thom Brown
• Running PostgreSQL as fast as possible no matter the consequences
  • From: A B
• Re: Simple (hopefully) throughput question?
  • From: Pierre C
• Re: Simple (hopefully) throughput question?
  • From: Nick Matheson
• Re: Simple (hopefully) throughput question?
  • From: Maciek Sakrejda
• Re: Simple (hopefully) throughput question?
  • From: Nick Matheson
• Re: Simple (hopefully) throughput question?
  • From: Vitalii Tymchyshyn
• Re: Simple (hopefully) throughput question?
  • From: Nick Matheson
• Re: Simple (hopefully) throughput question?
  • From: Nick Matheson
• Re: Simple (hopefully) throughput question?
  • From: Nick Matheson
• Re: Simple (hopefully) throughput question?
  • From: Nick Matheson
• Re: Simple (hopefully) throughput question?
  • From: Pierre C
• Re: Simple (hopefully) throughput question?
  • From: Andy Colson
• Re: Simple (hopefully) throughput question?
  • From: Marti Raudsepp
• Re: Simple (hopefully) throughput question?
  • From: Heikki Linnakangas
• Re: Bufer cache replacement LRU algorithm?
  • From: Kevin Grittner
• Simple (hopefully) throughput question?
  • From: Nick Matheson
• Re: Bufer cache replacement LRU algorithm?
  • From: Kenneth Marshall
• Bufer cache replacement LRU algorithm?
  • From: Mladen Gogala
• Re: Test
  • From: Robert Gravsjö
• Re: Array interface
  • From: Mladen Gogala
• Re: A query become very slow after upgrade from 8.1.10 to 8.4.5
  • From: Yaocl
• Re: Array interface
  • From: Conor Walsh
• Re: A query become very slow after upgrade from 8.1.10 to 8.4.5
  • From: Tom Lane
• Array interface
  • From: Mladen Gogala
• Test
  • From: Mladen Gogala
• Re: Insert performance with composite index
  • From: Cédric Villemain
• Re: Insert performance with composite index
  • From: Divakar Singh
• Re: Insert performance with composite index
  • From: hubert depesz lubaczewski
• Re: Insert performance with composite index
  • From: Cédric Villemain
• Re: Insert performance with composite index
  • From: hubert depesz lubaczewski
• A query become very slow after upgrade from 8.1.10 to 8.4.5
  • From: Yaocl
• Re: Insert performance with composite index
  • From: Andres Freund
• Re: Insert performance with composite index
  • From: Divakar Singh
• Re: Insert performance with composite index
  • From: Andres Freund
• Re: Insert performance with composite index
  • From: Divakar Singh
• Re: Insert performance with composite index
  • From: Andres Freund
• Re: Insert performance with composite index
  • From: Andres Freund
• Re: Insert performance with composite index
  • From: Cédric Villemain
• Re: Insert performance with composite index
  • From: Marti Raudsepp
• Re: Insert performance with composite index
  • From: Marti Raudsepp
• Re: Insert performance with composite index
  • From: Divakar Singh
• Insert performance with composite index
  • From: Divakar Singh
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Mark Kirkwood
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Marti Raudsepp
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Andres Freund
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Greg Smith
• Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Marti Raudsepp
• Re: Slow Query- Bad Row Estimate
  • From: Ozer, Pam
• Re: Slow Query- Bad Row Estimate
  • From: Tom Lane
• Re: Slow Query- Bad Row Estimate
  • From: Ozer, Pam
• Re: Slow Query- Bad Row Estimate
  • From: Josh Berkus
• Re: Slow Query- Bad Row Estimate
  • From: Tom Lane
• Re: Slow Query- Bad Row Estimate
  • From: Ozer, Pam
• Re: Slow Query- Bad Row Estimate
  • From: Ozer, Pam
• Re: Slow Query- Bad Row Estimate
  • From: Kevin Grittner
• Re: Slow Query- Bad Row Estimate
  • From: Tom Lane
• Re: BBU Cache vs. spindles
  • From: david
• Re: Slow Query- Bad Row Estimate
  • From: Josh Berkus
• Slow Query- Bad Row Estimate
  • From: Ozer, Pam
• Re: BBU Cache vs. spindles
  • From: James Mansion
• Re: MVCC and Implications for (Near) Real-Time Application
  • From: Pierre C
• Re: BBU Cache vs. spindles
  • From: david
• Re: typoed column name, but postgres didn't grump
  • From: Tom Lane
• Re: BBU Cache vs. spindles
  • From: Alvaro Herrera
• Re: typoed column name, but postgres didn't grump
  • From: Kevin Grittner
• Re: temporary tables, indexes, and query plans
  • From: Robert Haas
• Re: typoed column name, but postgres didn't grump
  • From: Tom Lane
• Re: MVCC and Implications for (Near) Real-Time Application
  • From: Kevin Grittner
• Re: MVCC and Implications for (Near) Real-Time Application
  • From: A.M.
• Re: temporary tables, indexes, and query plans
  • From: Justin Pitts
• Re: temporary tables, indexes, and query plans
  • From: Justin Pitts
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• Re: Stored procedure declared as VOLATILE => no good optimization is done
  • From: Damon Snyder
• MVCC and Implications for (Near) Real-Time Application
  • From: Steve Wong
• CPUs for new databases
  • From: Christian Elmerot @ One.com
• typoed column name, but postgres didn't grump
  • From: Jon Nelson
• Re: BBU Cache vs. spindles
  • From: Robert Haas
• Re: partitioning question 1
  • From: Igor Neyman
• Re: partitioning question 1
  • From: Ben
• Re: BBU Cache vs. spindles
  • From: Tom Lane
• Re: BBU Cache vs. spindles
  • From: Aidan Van Dyk
• Re: BBU Cache vs. spindles
  • From: Robert Haas
• Re: partitioning question 1
  • From: Igor Neyman
• Re: Massive update, memory usage
  • From: Emanuele Bracci Poste
• Re: Massive update, memory usage
  • From: Trenta sis
• Re: BBU Cache vs. spindles
  • From: Tom Lane
• Re: partitioning question 1
  • From: Ben
• Re: partitioning question 1
  • From: Joshua D. Drake
• Re: BBU Cache vs. spindles
  • From: James Mansion
• Re: partitioning question 1
  • From: Reid Thompson
• Re: partitioning question 1
  • From: Ben
• Re: partitioning question 1
  • From: Joshua D. Drake
• Re: partitioning question 1
  • From: Ben
• Re: partitioning question 1
  • From: Joshua D. Drake
• Re: partitioning question 1
  • From: Ben
• Re: how to get the total number of records in report
  • From: Merlin Moncure
• Re: how to get the total number of records in report
  • From: AI Rumman
• Re: how to get the total number of records in report
  • From: Merlin Moncure
• Re: partitioning question 1
  • From: Joshua D. Drake
• Re: how to get the total number of records in report
  • From: Robert Haas
• partitioning question 1
  • From: Ben
• Re: Query much faster with enable_seqscan=0
  • From: Robert Haas
• Re: Slow Query- Simple taking
  • From: Robert Haas
• Re: Massive update, memory usage
  • From: Cédric Villemain
• Re: How does PG know if data is in memory?
  • From: Cédric Villemain
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Jesper Krogh
• Re: Slow Query- Simple taking
  • From: Mladen Gogala
• Re: Slow Query- Simple taking
  • From: Richard Broersma
• Re: Slow Query- Simple taking
  • From: Mladen Gogala
• Re: Slow Query- Simple taking
  • From: Robert Haas
• Re: Slow Query- Simple taking
  • From: Robert Haas
• Re: Slow Query- Simple taking
  • From: Robert Haas
• Re: temporary tables, indexes, and query plans
  • From: Tom Lane
• Re: temporary tables, indexes, and query plans
  • From: Jon Nelson
• Re: Select count(*), the sequel
  • From: Kenneth Marshall
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: AIX slow buffer reads
  • From: André Volpato
• Re: Select count(*), the sequel
  • From: Pierre C
• Massive update, memory usage
  • From: Trenta sis
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Pavel Stehule
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Alex Hunsaker
• Re: BBU Cache vs. spindles
  • From: Rob Wultsch
• Re: Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Tom Lane
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• Re: How does PG know if data is in memory?
  • From: Francisco Reyes
• Re: Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Robert Haas
• Re: BBU Cache vs. spindles
  • From: Robert Haas
• Re: Massive update, memory usage
  • From: Craig Ringer
• Re: AIX slow buffer reads
  • From: Tom Lane
• Re: AIX slow buffer reads
  • From: Brad Nicholson
• Re: temporary tables, indexes, and query plans
  • From: Tom Lane
• Re: temporary tables, indexes, and query plans
  • From: Jon Nelson
• Re: Select count(*), the sequel
  • From: Tom Lane
• Re: temporary tables, indexes, and query plans
  • From: Tom Lane
• Re: AIX slow buffer reads
  • From: André Volpato
• Re: Select count(*), the sequel
  • From: Thomas Kellerer
• Re: Select count(*), the sequel
  • From: Kenneth Marshall
• Re: temporary tables, indexes, and query plans
  • From: Jon Nelson
• Re: Select count(*), the sequel
  • From: Kevin Grittner
• Re: AIX slow buffer reads
  • From: Tom Lane
• Re: CPUs for new databases
  • From: Greg Smith
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Tom Lane
• Re: Select count(*), the sequel
  • From: Pierre C
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Jesper Krogh
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Alex Hunsaker
• Re: temporary tables, indexes, and query plans
  • From: Tom Lane
• Re: temporary tables, indexes, and query plans
  • From: Jon Nelson
• Re: AIX slow buffer reads
  • From: Greg Smith
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Scott Carey
• Re: CPUs for new databases
  • From: Scott Marlowe
• Re: temporary tables, indexes, and query plans
  • From: Jon Nelson
• Re: Massive update, memory usage
  • From: Andreas Kretschmer
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Steve Singer
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Jesper Krogh
• Massive update, memory usage
  • From: Trenta sis
• Re: temporary tables, indexes, and query plans
  • From: Reid Thompson
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: CPUs for new databases
  • From: Scott Marlowe
• Re: temporary tables, indexes, and query plans
  • From: Jon Nelson
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: temporary tables, indexes, and query plans
  • From: Jon Nelson
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Mladen Gogala
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: CPUs for new databases
  • From: Josh Berkus
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Scott Carey
• Re: temporary tables, indexes, and query plans
  • From: Mladen Gogala
• temporary tables, indexes, and query plans
  • From: Jon Nelson
• Re: AIX slow buffer reads
  • From: André Volpato
• Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
  • From: Francisco Reyes
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
  • From: Tom Lane
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: David Wilson
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Reid Thompson
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Steve Singer
• Re: Running 9 in production? Sticking with 8.4.4 for a while?
  • From: Francisco Reyes
• Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
  • From: Francisco Reyes
• Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
  • From: Marcin Mirosław
• Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
  • From: Francisco Reyes
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
  • From: Pavel Stehule
• Regression: 8.3 2 seconds -> 8.4 100+ seconds
  • From: Francisco Reyes
• Re: AIX slow buffer reads
  • From: Brad Nicholson
• Re: Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Ivan Voras
• Re: CPUs for new databases
  • From: Scott Marlowe
• Re: CPUs for new databases
  • From: Scott Marlowe
• Re: CPUs for new databases
  • From: Yeb Havinga
• Re: BBU Cache vs. spindles
  • From: Rob Wultsch
• Re: odd postgresql performance (excessive lseek)
  • From: Tom Lane
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Tom Lane
• Re: odd postgresql performance (excessive lseek)
  • From: Robert Haas
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Robert Haas
• Re: Select count(*), the sequel
  • From: Robert Haas
• Re: CPUs for new databases
  • From: Scott Marlowe
• Re: CPUs for new databases
  • From: Ivan Voras
• Re: CPUs for new databases
  • From: James Cloos
• Slow Query- Bad Row Estimate
  • From: Ozer, Pam
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: Select count(*), the sequel
  • From: Tom Lane
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Robert Haas
• Re: Select count(*), the sequel
  • From: Robert Haas
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Mladen Gogala
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Jon Nelson
• Re: AIX slow buffer reads
  • From: André Volpato
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Mladen Gogala
• Re: CPUs for new databases
  • From: Josh Berkus
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: CPUs for new databases
  • From: Christian Elmerot
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Leonardo Francalanci
• Re: CPUs for new databases
  • From: Scott Marlowe
• Re: CPUs for new databases
  • From: Kevin Grittner
• Re: BBU Cache vs. spindles
  • From: Robert Haas
• Re: BBU Cache vs. spindles
  • From: Rob Wultsch
• Re: AIX slow buffer reads
  • From: Brad Nicholson
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• CPUs for new databases
  • From: Christian Elmerot
• Re: BBU Cache vs. spindles
  • From: Robert Haas
• Re: which one is faster
  • From: Mladen Gogala
• Re: Auto ANALYZE criteria
  • From: Robert Haas
• Re: No hash join across partitioned tables?
  • From: Robert Haas
• Re: which one is faster
  • From: Szymon Guz
• Re: which one is faster
  • From: Grzegorz Jaśkiewicz
• Re: which one is faster
  • From: Szymon Guz
• Re: which one is faster
  • From: Grzegorz Jaśkiewicz
• Re: which one is faster
  • From: Szymon Guz
• Re: which one is faster
  • From: Marcin Mirosław
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• Re: which one is faster
  • From: Szymon Guz
• which one is faster
  • From: AI Rumman
• Re: BBU Cache vs. spindles
  • From: Scott Carey
• Re: interpret statement log duration information
  • From: Tom Lane
• interpret statement log duration information
  • From: Mark Rostron
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Merlin Moncure
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Alan Hodgson
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Scott Marlowe
• Re: AIX slow buffer reads
  • From: André Volpato
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Ray Stell
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Mladen Gogala
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• Re: AIX slow buffer reads
  • From: Merlin Moncure
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Steve Singer
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Joshua D. Drake
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Josh Kupershmidt
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• AIX slow buffer reads
  • From: André Volpato
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Scott Marlowe
• Re: Postgres insert performance and storage requirement compared to Oracle
  • From: Joshua D. Drake
• Postgres insert performance and storage requirement compared to Oracle
  • From: Divakar Singh
• Re: Useless sort by
  • From: Gaetano Mendola
• Re: BBU Cache vs. spindles
  • From: Tom Lane
• Re: BBU Cache vs. spindles
  • From: Greg Smith
• Re: BBU Cache vs. spindles
  • From: Greg Smith
• Re: BBU Cache vs. spindles
  • From: James Mansion
• Re: BBU Cache vs. spindles
  • From: Josh Berkus
• Re: BBU Cache vs. spindles
  • From: Kevin Grittner
• Re: BBU Cache vs. spindles
  • From: Rob Wultsch
• Re: BBU Cache vs. spindles
  • From: Kevin Grittner
• Re: BBU Cache vs. spindles
  • From: Rob Wultsch
• Re: BBU Cache vs. spindles
  • From: Kevin Grittner
• Re: BBU Cache vs. spindles
  • From: Rob Wultsch
• Re: BBU Cache vs. spindles
  • From: Kevin Grittner
• Re: BBU Cache vs. spindles
  • From: Rob Wultsch
• Re: BBU Cache vs. spindles
  • From: Jesper Krogh
• Re: BBU Cache vs. spindles
  • From: Greg Smith
• Re: Periodically slow inserts
  • From: Gael Le Mignot
• Re: BBU Cache vs. spindles
  • From: Kevin Grittner
• Re: Periodically slow inserts
  • From: Leonardo Francalanci
• Re: BBU Cache vs. spindles
  • From: Greg Smith
• Re: BBU Cache vs. spindles
  • From: Tom Lane
• Re: BBU Cache vs. spindles
  • From: Greg Smith
• Re: Slow count(*) again...
  • From: Scott Carey
• Re: BBU Cache vs. spindles
  • From: Andres Freund
• Re: Index scan is not working, why??
  • From: Igor Neyman
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Re: BBU Cache vs. spindles
  • From: Kevin Grittner
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Re: BBU Cache vs. spindles
  • From: Kevin Grittner
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Experiences with running PostgreSQL on Blue Arc Network Storage
  • From: Tim Goodaire
• Re: How does PG know if data is in memory?
  • From: Bruce Momjian
• Re: BBU Cache vs. spindles
  • From: Kevin Grittner
• Re: Slow count(*) again...
  • From: Jesper Krogh
• Re: BBU Cache vs. spindles
  • From: Greg Smith
• Re: BBU Cache vs. spindles
  • From: Kevin Grittner
• Re: BBU Cache vs. spindles
  • From: Greg Smith
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Re: BBU Cache vs. spindles
  • From: Kevin Grittner
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Re: Periodically slow inserts
  • From: Tom Lane
• Re: BBU Cache vs. spindles
  • From: Steve Crawford
• Re: Periodically slow inserts
  • From: Mladen Gogala
• Re: New wiki page on write reliability
  • From: Bruce Momjian
• Re: Periodically slow inserts
  • From: Gael Le Mignot
• Re: Periodically slow inserts
  • From: Greg Smith
• Re: Periodically slow inserts
  • From: Cédric Villemain
• Re: New wiki page on write reliability
  • From: Greg Smith
• Re: Periodically slow inserts
  • From: Leonardo Francalanci
• Re: Periodically slow inserts
  • From: Leonardo Francalanci
• Re: Periodically slow inserts
  • From: Gael Le Mignot
• Re: Periodically slow inserts
  • From: Tom Lane
• Re: New wiki page on write reliability
  • From: Brad Nicholson
• New wiki page on write reliability
  • From: Greg Smith
• Re: Index scan is not working, why??
  • From: Mladen Gogala
• Re: Periodically slow inserts
  • From: Leonardo Francalanci
• Re: Periodically slow inserts
  • From: Kenneth Marshall
• Periodically slow inserts
  • From: Gael Le Mignot
• Re: Index scan is not working, why??
  • From: Scott Marlowe
• Re: Index scan is not working, why??
  • From: Samuel Gendler
• Index scan is not working, why??
  • From: AI Rumman
• Re: Slow count(*) again...
  • From: Scott Carey
• Re: BBU Cache vs. spindles
  • From: Scott Marlowe
• Re: Slow count(*) again...
  • From: Bruce Momjian
• Re: What is postmaster doing?
  • From: Greg Smith
• Re: BBU Cache vs. spindles
  • From: Joshua D. Drake
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Re: What is postmaster doing?
  • From: Scott Marlowe
• Re: What is postmaster doing?
  • From: Scott Marlowe
• Re: What is postmaster doing?
  • From: Tom Lane
• Re: What is postmaster doing?
  • From: Dimi Paun
• Re: What is postmaster doing?
  • From: Tom Lane
• Re: What is postmaster doing?
  • From: Dimi Paun
• Re: What is postmaster doing?
  • From: Mladen Gogala
• Re: What is postmaster doing?
  • From: Tom Lane
• Re: What is postmaster doing?
  • From: Jeff Davis
• Re: What is postmaster doing?
  • From: Dimi Paun
• Re: What is postmaster doing?
  • From: Reid Thompson
• What is postmaster doing?
  • From: Dimi Paun
• Re: how to get the total number of records in report
  • From: Merlin Moncure
• Re: Slow Query- Simple taking
  • From: Ozer, Pam
• Re: Slow Query- Simple taking
  • From: Mathieu De Zutter
• Re: Slow Query- Simple taking
  • From: Kevin Grittner
• Slow Query- Simple taking
  • From: Ozer, Pam
• Re: odd postgresql performance (excessive lseek)
  • From: Merlin Moncure
• Re: odd postgresql performance (excessive lseek)
  • From: Greg Smith
• Re: odd postgresql performance (excessive lseek)
  • From: Jon Nelson
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Kevin Grittner
• Re: odd postgresql performance (excessive lseek)
  • From: Tom Lane
• Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
  • From: Tom Lane
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Mladen Gogala
• Re: how to get the total number of records in report
  • From: Greg Spiegelberg
• Re: odd postgresql performance (excessive lseek)
  • From: Jon Nelson
• Re: odd postgresql performance (excessive lseek)
  • From: Merlin Moncure
• Re: odd postgresql performance (excessive lseek)
  • From: Jon Nelson
• Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
  • From: Eric Comeau
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Scott Carey
• Re: how to get the total number of records in report
  • From: AI Rumman