Postgres Performance Date Index

• Thread Index

• Re: How to fast the REINDEX
  • From: Hannu Krosing
• Re: Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: Hannu Krosing
• Re: Using high speed swap to improve performance?
  • From: Lew
• Some question
  • From: Ľubomír Varga
• Re: temp table "on commit delete rows": transaction overhead
  • From: Artiom Makarov
• Re: Using high speed swap to improve performance?
  • From: Christiaan Willemsen
• Re: query slow; strace output worrisome
  • From: Craig Ringer
• Re: query slow; strace output worrisome
  • From: Brian Cox
• Re: query slow; strace output worrisome
  • From: Craig Ringer
• query slow; strace output worrisome
  • From: Brian Cox
• Re: Huge table searching optimization
  • From: Oliver Kindernay
• Re: How to fast the REINDEX
  • From: Robert Haas
• Re: Huge table searching optimization
  • From: Tom Lane
• Re: Huge table searching optimization
  • From: Andres Freund
• Re: Using high speed swap to improve performance?
  • From: Greg Smith
• Re: Huge table searching optimization
  • From: hubert depesz lubaczewski
• Huge table searching optimization
  • From: Oliver Kindernay
• Re: temp table "on commit delete rows": transaction overhead
  • From: Bruce Momjian
• Re: Using high speed swap to improve performance?
  • From: Scott Marlowe
• Re: Using high speed swap to improve performance?
  • From: Robert Haas
• Re: Using high speed swap to improve performance?
  • From: Robert Haas
• Re: [GENERAL] ERROR: cache lookup failed for relation X
  • From: raghavendra t
• Re: [GENERAL] ERROR: cache lookup failed for relation X
  • From: Tom Lane
• Re: [GENERAL] ERROR: cache lookup failed for relation X
  • From: justin@xxxxxxxxxxxx
• ERROR: cache lookup failed for relation X
  • From: raghavendra t
• Re: How much memory is PostgreSQL using
  • From: Guillaume Lelarge
• David Crooke wants to stay in touch on LinkedIn
  • From: David Crooke
• Re: *** PROBABLY SPAM *** Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: John Beaver
• Re: Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: John Beaver
• Re: *** PROBABLY SPAM *** Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: Pierre C
• Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: Beaver, John E
• Re: How much memory is PostgreSQL using
  • From: Campbell, Lance
• Re: Using high speed swap to improve performance?
  • From: Arjen van der Meijden
• Using high speed swap to improve performance?
  • From: Christiaan Willemsen
• Re: Database size growing over time and leads to performance impact
  • From: Scott Carey
• Re: Database size growing over time and leads to performance impact
  • From: Tom Lane
• Re: Database size growing over time and leads to performance impact
  • From: Scott Carey
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Eliot Gable
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Robert Haas
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Eliot Gable
• Re: How to fast the REINDEX
  • From: Kevin Grittner
• Re: How to fast the REINDEX
  • From: Brad Nicholson
• Re: How to fast the REINDEX
  • From: raghavendra t
• Re: How to fast the REINDEX
  • From: Pierre C
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: How to fast the REINDEX
  • From: Greg Smith
• Re: How to fast the REINDEX
  • From: Steve Clark
• Re: How to fast the REINDEX
  • From: Craig Ringer
• Re: temp table "on commit delete rows": transaction overhead
  • From: Bruce Momjian
• Re: How to fast the REINDEX
  • From: raghavendra t
• Re: How to fast the REINDEX
  • From: Jaime Casanova
• Re: How to fast the REINDEX
  • From: Kevin Grittner
• Re: How to fast the REINDEX
  • From: raghavendra t
• Re: How to fast the REINDEX
  • From: Kevin Grittner
• Re: How to fast the REINDEX
  • From: raghavendra t
• Re: How to fast the REINDEX
  • From: Kevin Grittner
• Re: How to fast the REINDEX
  • From: raghavendra t
• Re: How to fast the REINDEX
  • From: Kevin Grittner
• How to fast the REINDEX
  • From: raghavendra t
• Re: Database size growing over time and leads to performance impact
  • From: Alvaro Herrera
• Re: Database size growing over time and leads to performance impact
  • From: Robert Haas
• Re: Database size growing over time and leads to performance impact
  • From: Scott Carey
• Re: query has huge variance in execution times
  • From: David Wilson
• Re: query has huge variance in execution times
  • From: Brian Cox
• Re: 3ware vs. MegaRAID
  • From: Francisco Reyes
• Re: experiments in query optimization
  • From: Robert Haas
• Re: mysql to postgresql, performance questions
  • From: Bruce Momjian
• Re: 3ware vs. MegaRAID
  • From: Matteo Beccati
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Matthew Wakeling
• Re: query has huge variance in execution times
  • From: David Wilson
• query has huge variance in execution times
  • From: Brian Cox
• Re: experiments in query optimization
  • From: Robert Haas
• Re: temp table "on commit delete rows": transaction overhead
  • From: Tom Lane
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: 3ware vs. MegaRAID
  • From: Greg Smith
• Re: 3ware vs. MegaRAID
  • From: Matteo Beccati
• Re: experiments in query optimization
  • From: Faheem Mitha
• transaction overhead at "on commit delete rows";
  • From: admin@xxxxxxxx
• temp table "on commit delete rows": transaction overhead
  • From: Artiom Makarov
• Re: Database size growing over time and leads to performance impact
  • From: Greg Smith
• Re: [ADMIN] Database size growing over time and leads to performance impact
  • From: Tomeh, Husam
• Re: experiments in query optimization
  • From: Kevin Grittner
• Re: REINDEXing database-wide daily
  • From: Kevin Grittner
• Re: why does swap not recover?
  • From: Robert Haas
• Re: Why Wal_buffer is 64KB
  • From: Robert Haas
• Re: REINDEXing database-wide daily
  • From: Andy Colson
• Re: Database size growing over time and leads to performance impact
  • From: Andy Colson
• 3ware vs. MegaRAID
  • From: Ireneusz Pluta
• Re: Database size growing over time and leads to performance impact
  • From: Gnanakumar
• Re: Performance regarding LIKE searches
  • From: Matthew Wakeling
• REINDEXing database-wide daily
  • From: Gnanakumar
• Re: why does swap not recover?
  • From: Josh Berkus
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Robert Haas
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Robert Haas
• Re: Performance regarding LIKE searches
  • From: Andy Colson
• Re: Performance regarding LIKE searches
  • From: randalls
• Re: Performance regarding LIKE searches
  • From: Tom Lane
• Re: How much memory is PostgreSQL using
  • From: Greg Smith
• Performance regarding LIKE searches
  • From: randalls
• How much memory is PostgreSQL using
  • From: Campbell, Lance
• Re: Optimizer showing wrong rows in plan
  • From: Nikolas Everett
• Re: Optimizer showing wrong rows in plan
  • From: raghavendra t
• Re: Optimizer showing wrong rows in plan
  • From: Matthew Wakeling
• Re: Why Wal_buffer is 64KB
  • From: Tadipathri Raghu
• Re: Why Wal_buffer is 64KB
  • From: Scott Marlowe
• Re: Why Wal_buffer is 64KB
  • From: Tadipathri Raghu
• Re: Optimizer showing wrong rows in plan
  • From: Tadipathri Raghu
• Re: Pgbench TPS Calculation
  • From: Greg Smith
• Re: Database size growing over time and leads to performance impact
  • From: Greg Smith
• Re: Forcing index scan on query produces 16x faster
  • From: Cédric Villemain
• Re: Optimizer showing wrong rows in plan
  • From: Tom Lane
• Re: Optimizer showing wrong rows in plan
  • From: Jeremy Harris
• Re: Optimizer showing wrong rows in plan
  • From: Tom Lane
• Re: Optimizer showing wrong rows in plan
  • From: Gary Doades
• Re: Optimizer showing wrong rows in plan
  • From: Frank Heikens
• Re: Optimizer showing wrong rows in plan
  • From: Tadipathri Raghu
• Re: Optimizer showing wrong rows in plan
  • From: Tadipathri Raghu
• Re: Optimizer showing wrong rows in plan
  • From: Szymon Guz
• Re: Optimizer showing wrong rows in plan
  • From: Tadipathri Raghu
• Re: Optimizer showing wrong rows in plan
  • From: Szymon Guz
• Re: why does swap not recover?
  • From: Richard Yen
• Optimizer showing wrong rows in plan
  • From: Tadipathri Raghu
• Pgbench TPS Calculation
  • From: Reydan Cankur
• Re: Database size growing over time and leads to performance impact
  • From: Pierre C
• Re: Database size growing over time and leads to performance impact
  • From: Andy Colson
• Database size growing over time and leads to performance impact
  • From: Gnanakumar
• Re: why does swap not recover?
  • From: Craig James
• Re: why does swap not recover?
  • From: Scott Carey
• Re: Block at a time ...
  • From: Scott Carey
• Re: pg_dump far too slow
  • From: Scott Carey
• Re: why does swap not recover?
  • From: Scott Marlowe
• why does swap not recover?
  • From: Richard Yen
• Re: Why Wal_buffer is 64KB
  • From: Scott Marlowe
• Re: Why Wal_buffer is 64KB
  • From: Pierre C
• Re: Performance Tuning Large PL/PGSQL Stored Procedure
  • From: Richard Huxton
• Re: Performance Tuning Large PL/PGSQL Stored Procedure
  • From: Merlin Moncure
• good effective_io_concurrency for FusionIO drives?
  • From: Richard Yen
• Re: Performance Tuning Large PL/PGSQL Stored Procedure
  • From: Eliot Gable
• Re: Why Wal_buffer is 64KB
  • From: Tadipathri Raghu
• Re: Performance Tuning Large PL/PGSQL Stored Procedure
  • From: Merlin Moncure
• experiments in query optimization
  • From: Faheem Mitha
• Re: mysql to postgresql, performance questions
  • From: Yeb Havinga
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Pierre C
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: James Mansion
• Re: mysql to postgresql, performance questions
  • From: Hannu Krosing
• tuning auto vacuum for highly active tables
  • From: Bhella Paramjeet-PFCW67
• Re: Why Wal_buffer is 64KB
  • From: Pierre C
• Re: Why Wal_buffer is 64KB
  • From: Jaime Casanova
• Re: Why Wal_buffer is 64KB
  • From: Brad Nicholson
• Re: default_statistics_target
  • From: Robert Haas
• Why Wal_buffer is 64KB
  • From: Tadipathri Raghu
• Re: memory question
  • From: Matthew Wakeling
• Re: memory question
  • From: Dave Crooke
• Re: Forcing index scan on query produces 16x faster
  • From: Robert Haas
• Re: memory question
  • From: Scott Marlowe
• Re: Forcing index scan on query produces 16x faster
  • From: Eger, Patrick
• memory question
  • From: Campbell, Lance
• Re: Forcing index scan on query produces 16x faster
  • From: Robert Haas
• Re: PostgreSQL upgraded to 8.2 but forcing index scan on query produces faster
  • From: Christian Brink
• Re: mysql to postgresql, performance questions
  • From: Chris Browne
• Re: mysql to postgresql, performance questions
  • From: Chris Browne
• Re: mysql to postgresql, performance questions
  • From: Greg Smith
• Re: mysql to postgresql, performance questions
  • From: Yeb Havinga
• Re: mysql to postgresql, performance questions
  • From: Yeb Havinga
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Dave Crooke
• Re: mysql to postgresql, performance questions
  • From: Tom Lane
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Dave Crooke
• Re: [ADMIN] tuning auto vacuum for highly active tables
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Ross J. Reedstrom
• Re: mysql to postgresql, performance questions
  • From: Greg Smith
• Performance Tuning Large PL/PGSQL Stored Procedure
  • From: Eliot Gable
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Tom Lane
• Re: mysql to postgresql, performance questions
  • From: Ross J. Reedstrom
• Re: Got that new server, now it's time for config!
  • From: Scott Mead
• Re: Got that new server, now it's time for config!
  • From: Greg Smith
• Re: Block at a time ...
  • From: Craig James
• Re: Got that new server, now it's time for config!
  • From: Dan Harris
• Re: PostgreSQL upgraded to 8.2 but forcing index scan on query produces faster
  • From: Eger, Patrick
• Got that new server, now it's time for config!
  • From: Carlo Stonebanks
• Re: default_statistics_target
  • From: Carlo Stonebanks
• Re: Block at a time ...
  • From: Greg Stark
• Re: Block at a time ...
  • From: Dave Crooke
• Re: Block at a time ...
  • From: Pierre C
• Re: PostgreSQL upgraded to 8.2 but forcing index scan on query produces faster
  • From: Tom Lane
• PostgreSQL upgraded to 8.2 but forcing index scan on query produces faster
  • From: Christian Brink
• Re: Block at a time ...
  • From: Scott Carey
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Justin Graf
• Re: Building multiple indexes concurrently
  • From: Justin Pitts
• Re: Building multiple indexes concurrently
  • From: Hannu Krosing
• Re: Building multiple indexes concurrently
  • From: Justin Pitts
• Re: mysql to postgresql, performance questions
  • From: Dave Crooke
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Yeb Havinga
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Tom Lane
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Matthew Wakeling
• Re: mysql to postgresql, performance questions
  • From: Pierre C
• Re: mysql to postgresql, performance questions
  • From: Merlin Moncure
• Re: pgbench installation
  • From: Greg Smith
• Re: GZIP of pre-zipped output
  • From: Scott Marlowe
• Re: GZIP of pre-zipped output
  • From: Craig Ringer
• Re: mysql to postgresql, performance questions
  • From: Dave Crooke
• Re: mysql to postgresql, performance questions
  • From: Merlin Moncure
• Re: pg_dump far too slow
  • From: Bob Lunney
• GZIP of pre-zipped output
  • From: Dave Crooke
• Re: pg_dump far too slow
  • From: David Newall
• Re: pg_dump far too slow
  • From: Tom Lane
• Re: pg_dump far too slow
  • From: Dave Crooke
• Re: pg_dump far too slow
  • From: Craig Ringer
• Re: pg_dump far too slow
  • From: David Newall
• Re: mysql to postgresql, performance questions
  • From: Andy Colson
• Re: GiST index performance
  • From: Yeb Havinga
• pgbench installation
  • From: Reydan Cankur
• Re: PG using index+filter instead only use index
  • From: Tom Lane
• Re: GiST index performance
  • From: Kenneth Marshall
• Re: PG using index+filter instead only use index
  • From: Alexandre de Arruda Paes
• Re: GiST index performance
  • From: Yeb Havinga
• Re: GiST index performance
  • From: Yeb Havinga
• Re: PG using index+filter instead only use index
  • From: Tom Lane
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Dave Crooke
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Stephen Frost
• Re: mysql to postgresql, performance questions
  • From: Merlin Moncure
• Re: mysql to postgresql, performance questions
  • From: Pierre C
• Re: Building multiple indexes concurrently
  • From: Andres Freund
• Re: GiST index performance
  • From: Yeb Havinga
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Kevin Grittner
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• PG using index+filter instead only use index
  • From: Alexandre de Arruda Paes
• too complex query plan for not exists query and multicolumn indexes
  • From: Corin
• Re: shared_buffers advice
  • From: Dimitri Fontaine
• Re: mysql to postgresql, performance questions
  • From: Dimitri Fontaine
• Re: mysql to postgresql, performance questions
  • From: Ivan Voras
• Re: Forcing index scan on query produces 16x faster
  • From: Dave Crooke
• Re: Building multiple indexes concurrently
  • From: Hannu Krosing
• Re: mysql to postgresql, performance questions
  • From: Arjen van der Meijden
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Magnus Hagander
• Re: shared_buffers advice
  • From: Greg Smith
• Re: mysql to postgresql, performance questions
  • From: Stephen Frost
• Re: mysql to postgresql, performance questions
  • From: Grzegorz Jaśkiewicz
• Re: mysql to postgresql, performance questions
  • From: Thom Brown
• Re: mysql to postgresql, performance questions
  • From: Kenneth Marshall
• Re: mysql to postgresql, performance questions
  • From: tv
• mysql to postgresql, performance questions
  • From: Corin
• Re: pg_dump far too slow
  • From: Matthew Wakeling
• Re: shared_buffers advice
  • From: Dimitri Fontaine
• Re: Forcing index scan on query produces 16x faster
  • From: Eger, Patrick
• Re: Testing FusionIO
  • From: Ben Chobot
• Re: Forcing index scan on query produces 16x faster
  • From: Tom Lane
• Re: Forcing index scan on query produces 16x faster
  • From: David Wilson
• Forcing index scan on query produces 16x faster
  • From: Christian Brink
• Re: Building multiple indexes concurrently
  • From: Greg Smith
• Re: Building multiple indexes concurrently
  • From: Alvaro Herrera
• Re: Testing FusionIO
  • From: david
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Testing FusionIO
  • From: Kenny Gorman
• Re: Building multiple indexes concurrently
  • From: Andres Freund
• Re: Testing FusionIO
  • From: Justin Pitts
• Re: Testing FusionIO
  • From: Justin Pitts
• Re: Testing FusionIO
  • From: Justin Pitts
• Re: Building multiple indexes concurrently
  • From: Greg Smith
• Re: Block at a time ...
  • From: Bob Lunney
• Re: Block at a time ...
  • From: Craig James
• Re: Block at a time ...
  • From: Dave Crooke
• Fwd: shared_buffers advice
  • From: VJK
• Re: Building multiple indexes concurrently
  • From: Rob Wultsch
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Building multiple indexes concurrently
  • From: Tom Lane
• Re: Block at a time ...
  • From: Tom Lane
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Testing FusionIO
  • From: Devrim GÜNDÜZ
• Re: Building multiple indexes concurrently
  • From: Greg Smith
• Re: Block at a time ...
  • From: Greg Stark
• Re: GiST index performance
  • From: Yeb Havinga
• Re: Block at a time ...
  • From: Pierre C
• Re: Building multiple indexes concurrently
  • From: Ben Chobot
• Building multiple indexes concurrently
  • From: Rob Wultsch
• Re: Block at a time ...
  • From: Alvaro Herrera
• Block at a time ...
  • From: Dave Crooke
• Re: shared_buffers advice
  • From: Greg Smith
• Re: shared_buffers advice
  • From: Alvaro Herrera
• Re: shared_buffers advice
  • From: Tom Lane
• Re: shared_buffers advice
  • From: Alvaro Herrera
• Re: shared_buffers advice
  • From: Tom Lane
• Re: shared_buffers advice
  • From: Alvaro Herrera
• Re: shared_buffers advice
  • From: Tom Lane
• Re: shared_buffers advice
  • From: Alvaro Herrera
• Re: shared_buffers advice
  • From: Greg Smith
• Re: shared_buffers advice
  • From: Greg Smith
• Re: Postgres DB maintainenance - vacuum and reindex
  • From: Ing. Marcos Ortiz Valmaseda
• Re: Postgres DB maintainenance - vacuum and reindex
  • From: Ben Chobot
• Re: Postgres DB maintainenance - vacuum and reindex
  • From: Scott Marlowe
• Re: GiST index performance
  • From: Yeb Havinga
• Postgres DB maintainenance - vacuum and reindex
  • From: Meena_Ramkumar
• Re: shared_buffers advice
  • From: Greg Stark
• Re: shared_buffers advice
  • From: Greg Stark
• Re: shared_buffers advice
  • From: Tom Lane
• Re: shared_buffers advice
  • From: Pierre C
• Re: shared_buffers advice
  • From: Nikolas Everett
• Re: shared_buffers advice
  • From: Pierre C
• Re: Is DBLINK transactional
  • From: Chris Browne
• Re: shared_buffers advice
  • From: Greg Smith
• Re: shared_buffers advice
  • From: Dave Crooke
• Re: pg_dump far too slow
  • From: Dave Crooke
• Re: GiST index performance
  • From: Robert Haas
• Re: pg_dump far too slow
  • From: Robert Haas
• Re: shared_buffers advice
  • From: Scott Marlowe
• Re: Is DBLINK transactional
  • From: Hannu Krosing
• [offtopic] Problems subscribing to Postgres mailing lists
  • From: Ognjen Blagojevic
• Re: shared_buffers advice
  • From: Paul McGarry
• shared_buffers advice
  • From: Paul McGarry
• Strange workaround for slow query
  • From: Kees van Dieren
• Re: shared_buffers advice
  • From: Scott Carey
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: VJK
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Matthew Wakeling
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: VJK
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Tom Lane
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Tom Lane
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: VJK
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Greg Smith
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Kevin Grittner
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Kevin Grittner
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: VJK
• Re: default_statistics_target
  • From: Greg Smith
• Re: default_statistics_target
  • From: Albe Laurenz
• Updated benchmarking category on the wiki
  • From: Greg Smith
• default_statistics_target
  • From: Carlo Stonebanks
• Re: pg_dump far too slow
  • From: Tom Lane
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: fkater@xxxxxxxxxxxxxx
• pg_dump far too slow
  • From: David Newall
• Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: Dave Crooke
• Deleting bytea, autovacuum, and 8.2/8.4 differences
  • From: fkater@xxxxxxxxxxxxxx
• Re: Is DBLINK transactional
  • From: Craig Ringer
• Re: Is DBLINK transactional
  • From: Jeff Davis
• Re: Is DBLINK transactional
  • From: Merlin Moncure
• Is DBLINK transactional
  • From: elias ghanem
• Re: shared_buffers advice
  • From: Greg Smith
• Re: How to SELECT
  • From: Angayarkanni
• Re: How to SELECT
  • From: Dave Crooke
• Re: How to SELECT
  • From: A. Kretschmer
• How to SELECT
  • From: Angayarkanni
• Re: shared_buffers advice
  • From: Ben Chobot
• shared_buffers advice
  • From: Paul McGarry
• Re: Strange workaround for slow query
  • From: Robert Haas
• Re: Strange workaround for slow query
  • From: Tom Lane
• Re: Strange workaround for slow query
  • From: Robert Haas
• Re: Bad query plan inside EXISTS clause
  • From: Benoit Delbosc
• Re: Strange workaround for slow query
  • From: Harald Fuchs
• Re: Bad query plan inside EXISTS clause
  • From: Tom Lane
• Re: Bad query plan inside EXISTS clause
  • From: Benoit Delbosc
• Re: Bad query plan inside EXISTS clause
  • From: Yeb Havinga
• Re: Bad query plan inside EXISTS clause
  • From: Yeb Havinga
• Re: Bad query plan inside EXISTS clause
  • From: Grzegorz Jaśkiewicz
• Re: Bad query plan inside EXISTS clause
  • From: Kenneth Marshall
• Bad query plan inside EXISTS clause
  • From: Benoit Delbosc
• Re: Strange workaround for slow query
  • From: Yeb Havinga
• Re: Strange workaround for slow query
  • From: sverhagen
• Re: Strange workaround for slow query
  • From: Yeb Havinga
• Re: Strange workaround for slow query
  • From: sverhagen
• Re: Strange workaround for slow query
  • From: Yeb Havinga
• Strange workaround for slow query
  • From: Kees van Dieren
• Strange workaround for slow query
  • From: sverhagen
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Scott Carey
• Re: 10K vs 15k rpm for analytics
  • From: Scott Carey
• Re: Deleting Large Objects
  • From: Kevin Grittner
• Deleting Large Objects
  • From: John KEA
• Re: Extracting superlatives - SQL design philosophy
  • From: Dave Crooke
• Re: 10K vs 15k rpm for analytics
  • From: Michael Stone
• Re: Out of shared memory in postgres 8.4.2 and locks
  • From: Merlin Moncure
• Re: 10K vs 15k rpm for analytics
  • From: Kevin Grittner
• Re: 10K vs 15k rpm for analytics
  • From: david
• Re: 10K vs 15k rpm for analytics
  • From: Ing. Marcos Ortiz Valmaseda
• Re: 10K vs 15k rpm for analytics
  • From: Pierre C
• Re: Out of shared memory in postgres 8.4.2 and locks
  • From: Vidhya Bondre
• Re: Extracting superlatives - SQL design philosophy
  • From: Merlin Moncure
• Re: Out of shared memory in postgres 8.4.2 and locks
  • From: Merlin Moncure
• Out of shared memory in postgres 8.4.2 and locks
  • From: Vidhya Bondre
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Scott Carey
• Re: 10K vs 15k rpm for analytics
  • From: Scott Carey
• Re: partition pruning
  • From: Simon Riggs
• Re: Estimation issue with partitioned tables
  • From: Robert Haas
• Re: Testing FusionIO
  • From: Ben Chobot
• Re: Testing FusionIO
  • From: Greg Smith
• Re: Paritioning vs. caching
  • From: Josh Berkus
• Re: Paritioning vs. caching
  • From: Anj Adu
• Paritioning vs. caching
  • From: Konrad Garus
• Re: Testing FusionIO
  • From: Ben Chobot
• Re: prepared statements and partitioning (partition elimination not working)
  • From: Kenneth Marshall
• prepared statements and partitioning (partition elimination not working)
  • From: Kevin Kempter
• Re: Testing FusionIO
  • From: Łukasz Jagiełło
• Re: Testing FusionIO
  • From: Yeb Havinga
• Testing FusionIO
  • From: Devrim GÜNDÜZ
• Re: Estimation issue with partitioned tables
  • From: Josh Berkus
• Re: partition pruning
  • From: Robert Haas
• Re: Estimation issue with partitioned tables
  • From: Robert Haas
• Re: Estimation issue with partitioned tables
  • From: Josh Berkus
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Robert Haas
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: Estimation issue with partitioned tables
  • From: Robert Haas
• Re: dbt2 performance
  • From: Robert Haas
• Re: SSD + RAID
  • From: Ron Mayer
• Re: 10K vs 15k rpm for analytics
  • From: Yeb Havinga
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Pierre C
• Re: 10K vs 15k rpm for analytics
  • From: Yeb Havinga
• Re: 10K vs 15k rpm for analytics
  • From: Yeb Havinga
• Re: 10K vs 15k rpm for analytics
  • From: Yeb Havinga
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: GiST index performance
  • From: Bruce Momjian
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: Query slowing down significantly??
  • From: Kris Jurka
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: david
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: david
• Re: 10K vs 15k rpm for analytics
  • From: Scott Marlowe
• Re: 10K vs 15k rpm for analytics
  • From: Dave Crooke
• Re: 10K vs 15k rpm for analytics
  • From: Greg Smith
• Re: 10K vs 15k rpm for analytics
  • From: Yeb Havinga
• 10K vs 15k rpm for analytics
  • From: Francisco Reyes
• Re: No hash join across partitioned tables?
  • From: Grzegorz Jaśkiewicz
• Re: GiST index performance
  • From: Robert Haas
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: GiST index performance
  • From: Robert Haas
• Re: No hash join across partitioned tables?
  • From: Robert Haas
• Re: SSD + RAID
  • From: Pierre C
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: Query slowing down significantly??
  • From: Yeb Havinga
• partition pruning
  • From: Anj Adu
• Re: Query slowing down significantly??
  • From: Rainer Pruy
• Re: Query slowing down significantly??
  • From: Tom Lane
• Re: Query slowing down significantly??
  • From: Rainer Pruy
• Re: Query slowing down significantly??
  • From: Tom Lane
• Re: Autovacuum Tuning advice
  • From: Plugge, Joe R.
• Query slowing down significantly??
  • From: Rainer Pruy
• Re: Autovacuum Tuning advice
  • From: Grzegorz Jaśkiewicz
• Re: Autovacuum Tuning advice
  • From: Plugge, Joe R.
• Re: Autovacuum Tuning advice
  • From: Greg Williamson
• Re: Autovacuum Tuning advice
  • From: Scott Marlowe
• Autovacuum Tuning advice
  • From: Plugge, Joe R.
• Re: [HACKERS] full text search index scan query plan changed in 8.4.2?
  • From: Chris
• Re: partitioned tables query not using indexes
  • From: Josh Berkus
• Re: [HACKERS] full text search index scan query plan changed in 8.4.2?
  • From: Josh Berkus
• Re: partitioned tables query not using indexes
  • From: Kenneth Marshall
• Re: partitioned tables query not using indexes
  • From: Josh Berkus
• Estimation issue with partitioned tables
  • From: Josh Berkus
• Re: How to troubleshoot high mem usage by postgres?
  • From: Tom Lane
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Ron Mayer
• Re: How to troubleshoot high mem usage by postgres?
  • From: Chris
• Re: How to troubleshoot high mem usage by postgres?
  • From: Chris
• Re: How to troubleshoot high mem usage by postgres?
  • From: Tom Lane
• Re: How to troubleshoot high mem usage by postgres?
  • From: Craig Ringer
• Re: How to troubleshoot high mem usage by postgres?
  • From: Ben Chobot
• How to troubleshoot high mem usage by postgres?
  • From: Chris
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Fernando Hevia
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Jorge Montero
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Ben Chobot
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: Multiple data base on same server
  • From: Ing. Marcos Ortiz Valmaseda
• Re: Multiple data base on same server
  • From: elias ghanem
• Re: Multiple data base on same server
  • From: Craig James
• Re: Multiple data base on same server
  • From: elias ghanem
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Kevin Grittner
• Re: Multiple data base on same server
  • From: Richard Huxton
• Re: Multiple data base on same server
  • From: Richard Huxton
• Multiple data base on same server
  • From: elias ghanem
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Greg Smith
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Devrim GÜNDÜZ
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Devrim GÜNDÜZ
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Jochen Erwied
• Re: bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• bgwriter, checkpoints, curious (seeing delays)
  • From: Tory M Blue
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: No hash join across partitioned tables?
  • From: Bruce Momjian
• Re: GiST index performance
  • From: Bruce Momjian
• Re: GiST index performance
  • From: Bruce Momjian
• Re: dbt2 performance
  • From: Yu-Ju Hong
• Re: dbt2 performance
  • From: Greg Smith
• dbt2 performance
  • From: Yu-Ju Hong
• Re: Extracting superlatives - SQL design philosophy
  • From: Tom Lane
• Re: Extracting superlatives - SQL design philosophy
  • From: Julien Theulier
• Re: Extracting superlatives - SQL design philosophy
  • From: Pierre C
• Re: Extracting superlatives - SQL design philosophy
  • From: Richard Huxton
• Re: Extracting superlatives - SQL design philosophy
  • From: Dave Crooke
• Re: Extracting superlatives - SQL design philosophy
  • From: Richard Huxton
• Re: Extracting superlatives - SQL design philosophy
  • From: Craig James
• Re: Extracting superlatives - SQL design philosophy
  • From: Dave Crooke
• Re: Extracting superlatives - SQL design philosophy
  • From: George Sexton
• Re: Extracting superlatives - SQL design philosophy
  • From: George Sexton
• Re: Extracting superlatives - SQL design philosophy
  • From: Garrett Murphy
• Re: Extracting superlatives - SQL design philosophy
  • From: Mose
• Extracting superlatives - SQL design philosophy
  • From: Dave Crooke
• Re: partitioned tables query not using indexes
  • From: Kevin Kempter
• Re: partitioned tables query not using indexes
  • From: A. Kretschmer
• Re: Internal operations when the planner makes a hash join.
  • From: Igor Neyman
• partitioned tables query not using indexes
  • From: Kevin Kempter
• Re: SSD + RAID
  • From: Dave Crooke
• Re: Planner question - "bit" data types
  • From: Scott Carey
• Thx and additional Q's .....
  • From: Dave Crooke
• Re: Internal operations when the planner makes a hash join.
  • From: Kevin Grittner
• Re: Internal operations when the planner makes a hash join.
  • From: negora
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Ben Chobot
• Re: Internal operations when the planner makes a hash join.
  • From: Kevin Grittner
• Re: Internal operations when the planner makes a hash join.
  • From: negora
• Re: SSD + RAID
  • From: Mark Mielke
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: SSD + RAID
  • From: david
• Re: SSD + RAID
  • From: Aidan Van Dyk
• Re: SSD + RAID
  • From: david
• Re: Internal operations when the planner makes a hash join.
  • From: Scott Carey
• Re: SSD + RAID
  • From: Scott Carey
• Re: Internal operations when the planner makes a hash join.
  • From: Alvaro Herrera
• Re: Internal operations when the planner makes a hash join.
  • From: negora
• Re: Internal operations when the planner makes a hash join.
  • From: Kevin Grittner
• Internal operations when the planner makes a hash join.
  • From: negora
• Internal operations when the planner makes a hash join.
  • From: negora
• Re: Slow query: table iteration (8.3)
  • From: Yeb Havinga
• Re: SSD + RAID
  • From: Nikolas Everett
• Re: SSD + RAID
  • From: Pierre C
• Re: SSD + RAID
  • From: david
• Re: Advice requested on structuring aggregation queries
  • From: Joe Conway
• Advice requested on structuring aggregation queries
  • From: Dave Crooke
• Re: Planner question - "bit" data types
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Scott Marlowe
• Re: SSD + RAID
  • From: Scott Marlowe
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Mark Mielke
• Re: SSD + RAID
  • From: Greg Smith
• Re: plpgsql plan cache
  • From: Joel Jacobson
• Re: plpgsql plan cache
  • From: Pierre C
• Re: plpgsql plan cache
  • From: Nikolas Everett
• Re: plpgsql plan cache
  • From: Tom Lane
• Re: plpgsql plan cache
  • From: Joel Jacobson
• Re: plpgsql plan cache
  • From: Pierre C
• plpgsql plan cache
  • From: Joel Jacobson
• Re: SSD + RAID
  • From: Ron Mayer
• Re: shared_buffers
  • From: Kevin Grittner
• shared_buffers
  • From: George Sexton
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: AutoVacuum_NapTime
  • From: Alvaro Herrera
• Re: SSD + RAID
  • From: Arjen van der Meijden
• Re: SSD + RAID
  • From: Greg Smith
• Re: Auto Vacuum out of memory
  • From: Robert Haas
• Re: SSD + RAID
  • From: Ron Mayer
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Scott Carey
• Re: can we optimize STACK_DEPTH_SLOP
  • From: terry
• Re: can we optimize STACK_DEPTH_SLOP
  • From: Tom Lane
• can we optimize STACK_DEPTH_SLOP
  • From: terry
• can we optimize STACK_DEPTH_SLOP
  • From: terry
• Re: AutoVacuum_NapTime
  • From: George Sexton
• Re: AutoVacuum_NapTime
  • From: Tom Lane
• AutoVacuum_NapTime
  • From: George Sexton
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Dan Langille
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: bgwriter tunables vs pg_stat_bgwriter
  • From: Jeff
• Re: index usage in not like
  • From: A. Kretschmer
• Re: index usage in not like
  • From: Thom Brown
• Re: index usage in not like
  • From: Kenneth Marshall
• Re: index usage in not like
  • From: A. Kretschmer
• Re: index usage in not like
  • From: Thom Brown
• Re: index usage in not like
  • From: Thom Brown
• index usage in not like
  • From: AI Rumman
• Michael Clemmons wants to stay in touch on LinkedIn
  • From: Michael Clemmons
• Re: bgwriter tunables vs pg_stat_bgwriter
  • From: Greg Smith
• Re: bgwriter tunables vs pg_stat_bgwriter
  • From: Brad Nicholson
• Re: disk space usage unexpected
  • From: Rose Zhou
• Re: disk space usage unexpected
  • From: Ben Chobot
• bgwriter tunables vs pg_stat_bgwriter
  • From: Jeff
• Re: Dell PERC H700/H800
  • From: Stefan Kaltenbrunner
• Re: 8.1 -> 8.4 regression
  • From: Tom Lane
• Re: another 8.1->8.4 regression
  • From: Ben Chobot
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Jeff Davis
• another 8.1->8.4 regression
  • From: Ben Chobot
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: Why index is not using here?
  • From: Kevin Grittner
• Re: Dell PERC H700/H800
  • From: Bruce Momjian
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: Kevin Grittner
• Re: Why index is not using here?
  • From: AI Rumman
• Why index is not using here?
  • From: AI Rumman
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: disk space usage unexpected
  • From: Joshua D. Drake
• Re: disk space usage unexpected
  • From: Rose Zhou
• Re: disk space usage unexpected
  • From: Ben Chobot
• Auto Vacuum out of memory
  • From: Rose Zhou
• disk space usage unexpected
  • From: Rose Zhou
• Re: 8.1 -> 8.4 regression
  • From: Ben Chobot
• Re: 8.1 -> 8.4 regression
  • From: Tom Lane
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: Scott Marlowe
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Robert Haas
• Re: 8.1 -> 8.4 regression
  • From: Ben Chobot
• Re: 8.1 -> 8.4 regression
  • From: Kevin Grittner
• Re: Why primary key index are not using in joining?
  • From: Tom Lane
• Re: PostgreSQL on SMP Architectures
  • From: Kevin Grittner
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: Kevin Grittner
• Re: Why primary key index are not using in joining?
  • From: Yeb Havinga
• Re: 8.1 -> 8.4 regression
  • From: Dennis Björklund
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: Why primary key index are not using in joining?
  • From: Scott Marlowe
• Why primary key index are not using in joining?
  • From: AI Rumman
• Re: PostgreSQL on SMP Architectures
  • From: Boszormenyi Zoltan
• Re: PostgreSQL on SMP Architectures
  • From: Reydan Cankur
• 8.1 -> 8.4 regression
  • From: Ben Chobot
• Re: PostgreSQL on SMP Architectures
  • From: Scott Marlowe
• Re: PostgreSQL on SMP Architectures
  • From: Arjen van der Meijden
• PostgreSQL on SMP Architectures
  • From: Reydan Cankur
• Re: Deferred constraint and delete performance
  • From: Віталій Тимчишин
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Pierre Frédéric Caillaud
• Re: Dell PERC H700/H800
  • From: Scott Marlowe
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: Dell PERC H700/H800
  • From: Greg Smith
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Greg Smith
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: Kevin Grittner