Postgres Performance Date Index

• Thread Index

• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Tom Lane
• Re: unexpected query failure: ERROR: GIN indexes do not support whole-index scans
  • From: Jon Nelson
• HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Scott Carey
• Re: unexpected query failure: ERROR: GIN indexes do not support whole-index scans
  • From: Tom Lane
• unexpected query failure: ERROR: GIN indexes do not support whole-index scans
  • From: Jon Nelson
• Re: how to get the total number of records in report
  • From: Josh Kupershmidt
• Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
  • From: Tom Lane
• Re: No hash join across partitioned tables?
  • From: Alvaro Herrera
• Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
  • From: Mladen Gogala
• Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
  • From: Tom Lane
• Re: Select count(*), the sequel
  • From: Mladen Gogala
• Re: Select count(*), the sequel
  • From: Vitalii Tymchyshyn
• Re: No hash join across partitioned tables?
  • From: Samuel Gendler
• Select count(*), the sequel
  • From: Mladen Gogala
• Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
  • From: Eric Comeau
• Re: Index scan / Index cond limitation or ?
  • From: Nikolai Zhubr
• how to get the total number of records in report
  • From: AI Rumman
• Re: Stored procedure declared as VOLATILE => no good optimization is done
  • From: Merlin Moncure
• Re: UUID performance as primary key
  • From: Merlin Moncure
• Re: Select count(*), the sequel
  • From: Kenneth Marshall
• Re: UUID performance as primary key
  • From: Craig James
• Select count(*), the sequel
  • From: Mladen Gogala
• Re: No hash join across partitioned tables?
  • From: Alvaro Herrera
• Re: No hash join across partitioned tables?
  • From: Samuel Gendler
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: No hash join across partitioned tables?
  • From: Alvaro Herrera
• Re: UUID performance as primary key
  • From: Andy
• Re: Slow count(*) again...
  • From: Greg Smith
• Re: UUID performance as primary key
  • From: Craig Ringer
• Re: Stored procedure declared as VOLATILE => no good optimization is done
  • From: Tom Lane
• UUID performance as primary key
  • From: Navkirat Singh
• Re: Stored procedure declared as VOLATILE => no good optimization is done
  • From: Tatsuo Ishii
• Re: Stored procedure declared as VOLATILE => no good optimization is done
  • From: Merlin Moncure
• Re: Stored procedure declared as VOLATILE => no good optimization is done
  • From: Kevin Grittner
• Re: oracle to psql migration - slow query in postgres
  • From: Tony Capobianco
• Re: oracle to psql migration - slow query in postgres
  • From: Igor Neyman
• Re: help with understanding EXPLAIN and boosting performance
  • From: Tom Lane
• Re: Index scan / Index cond limitation or ?
  • From: Tom Lane
• Re: oracle to psql migration - slow query in postgres
  • From: Tony Capobianco
• Re: oracle to psql migration - slow query in postgres
  • From: Igor Neyman
• help with understanding EXPLAIN
  • From: Brandon Casci
• Re: Auto ANALYZE criteria
  • From: Joe Miller
• Index scan / Index cond limitation or ?
  • From: Nikolai Zhubr
• help with understanding EXPLAIN and boosting performance
  • From: Brandon Casci
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Stored procedure declared as VOLATILE => no good optimization is done
  • From: Damon Snyder
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: oracle to psql migration - slow query in postgres
  • From: Maciek Sakrejda
• Re: oracle to psql migration - slow query in postgres
  • From: Tony Capobianco
• Re: oracle to psql migration - slow query in postgres
  • From: Merlin Moncure
• Re: oracle to psql migration - slow query in postgres
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Devrim GÜNDÜZ
• Re: oracle to psql migration - slow query in postgres
  • From: Samuel Gendler
• odd postgresql performance (excessive lseek)
  • From: Jon Nelson
• Re: Slow count(*) again...
  • From: Jesper Krogh
• Re: oracle to psql migration - slow query in postgres
  • From: Mladen Gogala
• Re: oracle to psql migration - slow query in postgres
  • From: Jon Nelson
• Re: oracle to psql migration - slow query in postgres
  • From: Pierre C
• Re: oracle to psql migration - slow query in postgres
  • From: Cédric Villemain
• Re: oracle to psql migration - slow query in postgres
  • From: Ivan Voras
• Re: oracle to psql migration - slow query in postgres
  • From: bricklen
• Re: Slow count(*) again...
  • From: Robert Haas
• oracle to psql migration - slow query in postgres
  • From: Tony Capobianco
• Re: How does PG know if data is in memory?
  • From: Cédric Villemain
• Re: Slow count(*) again...
  • From: Jesper Krogh
• Re: SQL functions vs. PL/PgSQL functions
  • From: Tom Lane
• Re: SQL functions vs. PL/PgSQL functions
  • From: Merlin Moncure
• Re: Bogus startup cost for WindowAgg
  • From: Ants Aasma
• Re: Slow count(*) again...
  • From: mark
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: Robert Haas
• Re: Bogus startup cost for WindowAgg
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Mark Kirkwood
• Re: Slow count(*) again...
  • From: Mark Kirkwood
• Re: Bogus startup cost for WindowAgg
  • From: Tom Lane
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: david
• Re: Bogus startup cost for WindowAgg
  • From: Mladen Gogala
• Re: SQL functions vs. PL/PgSQL functions
  • From: Reuven M. Lerner
• Re: Slow count(*) again...
  • From: Alex Hunsaker
• Re: Slow count(*) again...
  • From: Alex Hunsaker
• Re: Slow count(*) again...
  • From: Jesper Krogh
• Bogus startup cost for WindowAgg
  • From: Ants Aasma
• Re: SQL functions vs. PL/PgSQL functions
  • From: Tom Lane
• Re: SQL functions vs. PL/PgSQL functions
  • From: Merlin Moncure
• Re: Slow count(*) again...
  • From: Tom Lane
• Re: Slow count(*) again...
  • From: Kevin Grittner
• Re: Slow count(*) again...
  • From: Robert Haas
• Re: Slow count(*) again...
  • From: Robert Haas
• Re: Slow count(*) again...
  • From: Greg Smith
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Greg Smith
• Re: Slow count(*) again...
  • From: Craig Ringer
• Re: Slow count(*) again...
  • From: Vitalii Tymchyshyn
• Re: Slow count(*) again...
  • From: Vitalii Tymchyshyn
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: Mark Kirkwood
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: SQL functions vs. PL/PgSQL functions
  • From: Craig Ringer
• Re: Slow count(*) again...
  • From: Pierre C
• SQL functions vs. PL/PgSQL functions
  • From: Reuven M. Lerner
• Re: Slow count(*) again...
  • From: Mark Kirkwood
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: Robert Haas
• Re: How does PG know if data is in memory?
  • From: Robert Haas
• Re: How does PG know if data is in memory?
  • From: Ron Mayer
• Re: Query much faster with enable_seqscan=0
  • From: Samuel Gendler
• Re: Query much faster with enable_seqscan=0
  • From: Ogden
• Re: Slow count(*) again...
  • From: Dan Harris
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: Pierre C
• Re: bulk load performance question
  • From: Tom Lane
• Re: read only transactions
  • From: Tom Lane
• bulk load performance question
  • From: Samuel Gendler
• Re: read only transactions
  • From: Chris Browne
• Re: read only transactions
  • From: Tom Lane
• Re: read only transactions
  • From: Kevin Grittner
• Re: Slow count(*) again...
  • From: Tom Lane
• Re: Slow count(*) again...
  • From: Jesper Krogh
• Re: Slow count(*) again...
  • From: Mladen Gogala
• read only transactions
  • From: Jon Nelson
• Re: Slow count(*) again...
  • From: Tom Lane
• Re: Slow count(*) again...
  • From: Dan Harris
• Re: large dataset with write vs read clients
  • From: Chris Browne
• Re: large dataset with write vs read clients
  • From: Chris Browne
• Re: Slow count(*) again...
  • From: Scott Carey
• Re: Slow count(*) again...
  • From: Scott Carey
• Re: Slow count(*) again...
  • From: Scott Carey
• Re: Slow count(*) again...
  • From: Jesper Krogh
• Re: Slow count(*) again...
  • From: Scott Carey
• Re: Slow count(*) again...
  • From: Chris Browne
• Re: Slow count(*) again...
  • From: Samuel Gendler
• Re: Slow count(*) again...
  • From: Scott Carey
• Re: Slow count(*) again...
  • From: david
• Re: Slow count(*) again...
  • From: david
• Re: Slow count(*) again...
  • From: david
• Re: Slow count(*) again...
  • From: Dan Harris
• Re: Slow count(*) again...
  • From: Kevin Grittner
• Re: Slow count(*) again...
  • From: bricklen
• Re: How does PG know if data is in memory?
  • From: Kevin Grittner
• Re: How does PG know if data is in memory?
  • From: gnuoytr
• Re: How does PG know if data is in memory?
  • From: Kevin Grittner
• Re: Slow count(*) again...
  • From: Joe Uhl
• Re: How does PG know if data is in memory?
  • From: gnuoytr
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Kevin Grittner
• Re: Slow count(*) again...
  • From: Tom Lane
• Re: Slow count(*) again...
  • From: Jon Nelson
• Re: Slow count(*) again...
  • From: Luca Tettamanti
• Re: Slow count(*) again...
  • From: Greg Smith
• Re: Slow count(*) again...
  • From: Jon Nelson
• Re: Runtime dependency from size of a bytea field
  • From: Robert Haas
• Re: How does PG know if data is in memory?
  • From: Robert Haas
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Craig Ringer
• Re: Slow count(*) again...
  • From: Vitalii Tymchyshyn
• Re: Slow count(*) again...
  • From: david
• Re: Slow count(*) again...
  • From: Craig Ringer
• Re: Slow count(*) again...
  • From: Vitalii Tymchyshyn
• Re: Slow count(*) again...
  • From: Greg Smith
• Re: Slow count(*) again...
  • From: Greg Smith
• Re: Slow count(*) again...
  • From: david
• Re: Slow count(*) again...
  • From: Samuel Gendler
• Re: Slow count(*) again...
  • From: Scott Carey
• Re: Slow count(*) again...
  • From: Samuel Gendler
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: How does PG know if data is in memory?
  • From: gnuoytr
• Re: How does PG know if data is in memory?
  • From: Robert Haas
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Scott Carey
• Re: Slow count(*) again...
  • From: Greg Smith
• Re: Slow count(*) again...
  • From: Scott Carey
• Re: gist indexes for distance calculations
  • From: Robert Haas
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Samuel Gendler
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: XFS vs Ext3, and schedulers, for WAL
  • From: Josh Berkus
• Re: XFS vs Ext3, and schedulers, for WAL
  • From: Joshua D. Drake
• Re: XFS vs Ext3, and schedulers, for WAL
  • From: Josh Berkus
• Re: Slow count(*) again...
  • From: Craig James
• Re: Slow count(*) again...
  • From: Pierre C
• Re: join order
  • From: Scott Marlowe
• join order
  • From: AI Rumman
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: Craig Ringer
• Re: Slow count(*) again...
  • From: Joshua Tolley
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Craig Ringer
• Re: Slow count(*) again...
  • From: Joshua Tolley
• Re: Slow count(*) again...
  • From: Jon Nelson
• Re: Slow count(*) again...
  • From: Craig Ringer
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: Reid Thompson
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Reid Thompson
• Re: Slow count(*) again...
  • From: Craig Ringer
• Re: large dataset with write vs read clients
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Віталій Тимчишин
• Re: large dataset with write vs read clients
  • From: Florian Weimer
• Re: DB slow down after table partition
  • From: Thom Brown
• DB slow down after table partition
  • From: AI Rumman
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Db slow down after table partition
  • From: AI Rumman
• Re: large dataset with write vs read clients
  • From: Craig Ringer
• Re: Slow count(*) again...
  • From: Craig Ringer
• Re: Slow count(*) again...
  • From: Craig Ringer
• Re: large dataset with write vs read clients
  • From: Mladen Gogala
• Re: large dataset with write vs read clients
  • From: Craig Ringer
• Re: Slow count(*) again...
  • From: Samuel Gendler
• Re: Slow count(*) again...
  • From: Neil Whelchel
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Joe Conway
• Re: Slow count(*) again...
  • From: Mladen Gogala
• Re: Slow count(*) again...
  • From: Scott Marlowe
• Slow count(*) again...
  • From: Neil Whelchel
• Re: large dataset with write vs read clients
  • From: Mladen Gogala
• Re: large dataset with write vs read clients
  • From: Florian Weimer
• Re: BBU Cache vs. spindles
  • From: Ben Chobot
• Re: Runtime dependency from size of a bytea field
  • From: Sander, Ingo (NSN - DE/Munich)
• BBU Cache vs. spindles
  • From: Steve Crawford
• Re: large dataset with write vs read clients
  • From: Aaron Turner
• Re: Odd behaviour with redundant CREATE statement
  • From: Dave Crooke
• Re: large dataset with write vs read clients
  • From: Greg Smith
• Re: Odd behaviour with redundant CREATE statement
  • From: Robert Haas
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Robert Haas
• Re: large dataset with write vs read clients
  • From: Aaron Turner
• Re: large dataset with write vs read clients
  • From: Stephen Frost
• Re: large dataset with write vs read clients
  • From: Stephen Frost
• Re: large dataset with write vs read clients
  • From: Stephen Frost
• Re: large dataset with write vs read clients
  • From: Dan Harris
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Kevin Grittner
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Stephen Frost
• large dataset with write vs read clients
  • From: Aaron Turner
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Kevin Grittner
• Re: Runtime dependency from size of a bytea field
  • From: Merlin Moncure
• Re: Runtime dependency from size of a bytea field
  • From: Merlin Moncure
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Ivan Voras
• Re: Optimizing query
  • From: Srikanth K
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Robert Haas
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Ivan Voras
• Re: On Scalability
  • From: Vincenzo Romano
• Re: Runtime dependency from size of a bytea field
  • From: Sander, Ingo (NSN - DE/Munich)
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Stephen Frost
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Robert Haas
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Stephen Frost
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Tom Lane
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Robert Haas
• XFS vs Ext3, and schedulers, for WAL
  • From: Josh Berkus
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Jon Nelson
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Ivan Voras
• Re: Runtime dependency from size of a bytea field
  • From: Merlin Moncure
• Re: Runtime dependency from size of a bytea field
  • From: Sander, Ingo (NSN - DE/Munich)
• Re: Runtime dependency from size of a bytea field
  • From: Merlin Moncure
• Re: Runtime dependency from size of a bytea field
  • From: Sander, Ingo (NSN - DE/Munich)
• Re: Runtime dependency from size of a bytea field
  • From: Craig Ringer
• Re: Error message in wal_log for Streaming replication
  • From: Jeff Davis
• Re: Runtime dependency from size of a bytea field
  • From: Merlin Moncure
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Dan Ports
• Error message in wal_log for Streaming replication
  • From: Nimesh Satam
• Runtime dependency from size of a bytea field
  • From: Sander, Ingo (NSN - DE/Munich)
• Re: Issue for partitioning with extra check constriants
  • From: Tom Lane
• Re: How does PG know if data is in memory?
  • From: Jeremy Harris
• Re: How does PG know if data is in memory?
  • From: Cédric Villemain
• Re: MIT benchmarks pgsql multicore (up to 48)performance
  • From: Scott Marlowe
• Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
  • From: Josh Berkus
• Re: Issue for partitioning with extra check constriants
  • From: Joshua D. Drake
• Re: Issue for partitioning with extra check constriants
  • From: Josh Berkus
• MIT benchmarks pgsql multicore (up to 48)performance
  • From: Hakan Kocaman
• Re: How does PG know if data is in memory?
  • From: Greg Smith
• Re: How does PG know if data is in memory?
  • From: Greg Smith
• Re: How does PG know if data is in memory?
  • From: Greg Smith
• Re: How does PG know if data is in memory?
  • From: Greg Smith
• Re: How does PG know if data is in memory?
  • From: Greg Smith
• Re: Wrong index choice
  • From: Tom Lane
• Re: How does PG know if data is in memory?
  • From: Craig Ringer
• Re: Issue for partitioning with extra check constriants
  • From: Tom Lane
• Re: Issue for partitioning with extra check constriants
  • From: Josh Berkus
• Re: Issue for partitioning with extra check constriants
  • From: Tom Lane
• Issue for partitioning with extra check constriants
  • From: Josh Berkus
• Re: turn off caching for performance test
  • From: Willy-Bas Loos
• Re: gist indexes for distance calculations
  • From: Marcelo Zabani
• Re: How does PG know if data is in memory?
  • From: Samuel Gendler
• Re: gist indexes for distance calculations
  • From: Merlin Moncure
• Re: How does PG know if data is in memory?
  • From: Tom Lane
• Re: How does PG know if data is in memory?
  • From: Fabrício dos Anjos Silva
• Re: How does PG know if data is in memory?
  • From: Pierre C
• Re: How does PG know if data is in memory?
  • From: Kevin Grittner
• Re: How does PG know if data is in memory?
  • From: Craig Ringer
• Re: How does PG know if data is in memory?
  • From: Fabrício dos Anjos Silva
• Re: gist indexes for distance calculations
  • From: Jesper Krogh
• Re: gist indexes for distance calculations
  • From: Karim Nassar
• Re: gist indexes for distance calculations
  • From: Marcelo Zabani
• Re: Memory usage - indexes
  • From: Mark Kirkwood
• Re: gist indexes for distance calculations
  • From: Tom Lane
• gist indexes for distance calculations
  • From: Marcelo Zabani
• Re: turn off caching for performance test
  • From: Willy-Bas Loos
• Re: postgresql-9.0 Windows service stops after database transaction
  • From: adrian . kitchingman
• Re: Performance improvements/regressions from 8.4 to 9.0?
  • From: Greg Smith
• Performance improvements/regressions from 8.4 to 9.0?
  • From: Andy
• Re: Wrong index choice
  • From: Kevin Grittner
• Re: How does PG know if data is in memory?
  • From: Samuel Gendler
• Wrong index choice
  • From: Fabrício dos Anjos Silva
• Re: How does PG know if data is in memory?
  • From: Kevin Grittner
• How does PG know if data is in memory?
  • From: Fabrício dos Anjos Silva
• Re: Memory usage - indexes
  • From: Tobias Brox
• Re: Memory usage - indexes
  • From: Mark Kirkwood
• Re: Memory usage - indexes
  • From: Tobias Brox
• Re: Running 9 in production? Sticking with 8.4.4 for a while?
  • From: Tory M Blue
• Re: Running 9 in production? Sticking with 8.4.4 for a while?
  • From: Guy Rouillier
• Re: Running 9 in production? Sticking with 8.4.4 for a while?
  • From: Greg Smith
• Re: Running 9 in production? Sticking with 8.4.4 for a while?
  • From: Michael Gould
• Running 9 in production? Sticking with 8.4.4 for a while?
  • From: Tory M Blue
• Re: Query much faster with enable_seqscan=0
  • From: Robert Haas
• Re: Clean up of archived Xlogs in postgres-9.
  • From: Erik Rijkers
• Clean up of archived Xlogs in postgres-9.
  • From: Nimesh Satam
• Re: postgresql-9.0 Windows service stops after database transaction
  • From: Craig Ringer
• Re: Odd behaviour with redundant CREATE statement
  • From: Gurjeet Singh
• Odd behaviour with redundant CREATE statement
  • From: Dave Crooke
• Re: how to enforce index sub-select over filter+seqscan
  • From: Robert Haas
• Re: Memory speed testing
  • From: Greg Smith
• Re: postgresql-9.0 Windows service stops after database transaction
  • From: adrian . kitchingman
• Re: postgresql-9.0 Windows service stops after database transaction
  • From: adrian . kitchingman
• Re: Is disableing nested_loops a bad idea ?
  • From: Robert Haas
• Re: turn off caching for performance test
  • From: Robert Haas
• Re: Memory usage - indexes
  • From: Tobias Brox
• Re: Memory usage - indexes
  • From: Greg Smith
• Re: Memory usage - indexes
  • From: Tobias Brox
• Re: Memory usage - indexes
  • From: Tobias Brox
• Re: Memory usage - indexes
  • From: Tobias Brox
• Re: Memory usage - indexes
  • From: Tobias Brox
• Re: Memory usage - indexes
  • From: Brad Nicholson
• Re: Memory usage - indexes
  • From: Bob Lunney
• Re: Memory usage - indexes
  • From: Brad Nicholson
• Re: Memory usage - indexes
  • From: Greg Smith
• Re: Memory usage - indexes
  • From: Greg Smith
• Re: Memory usage - indexes
  • From: Kevin Grittner
• Re: Memory usage - indexes
  • From: Tobias Brox
• Re: Query much faster with enable_seqscan=0
  • From: Scott Carey
• Re: Memory usage - indexes
  • From: Brad Nicholson
• Re: Memory usage - indexes
  • From: Tobias Brox
• Re: Memory usage - indexes
  • From: Tobias Brox
• Re: Memory usage - indexes
  • From: Bob Lunney
• Re: Memory usage - indexes
  • From: Kevin Grittner
• Re: postgresql-9.0 Windows service stops after database transaction
  • From: Thom Brown
• postgresql-9.0 Windows service stops after database transaction
  • From: adrian . kitchingman
• Re: locking issue on simple selects?
  • From: Kevin Grittner
• Re: locking issue on simple selects?
  • From: Tobias Brox
• Re: Memory usage - indexes
  • From: Mark Kirkwood
• Memory usage - indexes
  • From: Tobias Brox
• Re: locking issue on simple selects?
  • From: Kevin Grittner
• Re: locking issue on simple selects?
  • From: Tobias Brox
• Re: how to enforce index sub-select over filter+seqscan
  • From: Merlin Moncure
• Re: Useless sort by
  • From: Scott Marlowe
• Re: how to enforce index sub-select over filter+seqscan
  • From: Kevin Grittner
• how to enforce index sub-select over filter+seqscan
  • From: Dmitry Teslenko
• Re: Useless sort by
  • From: gnuoytr
• Re: Using Between
  • From: mark
• Re: Useless sort by
  • From: Robert Haas
• Re: Useless sort by
  • From: Scott Marlowe
• Re: Useless sort by
  • From: Greg Smith
• Re: Useless sort by
  • From: gnuoytr
• Re: Useless sort by
  • From: Robert Haas
• Re: Using Between
  • From: Ozer, Pam
• Re: Using Between
  • From: Robert Haas
• Re: Using Between
  • From: Ozer, Pam
• Re: Query much faster with enable_seqscan=0
  • From: Ogden
• Re: Using Between
  • From: Robert Haas
• Re: Performance degradation, index bloat and planner estimates
  • From: Tom Lane
• Re: Performance degradation, index bloat and planner estimates
  • From: Craig Ringer
• Re: Query much faster with enable_seqscan=0
  • From: Tom Lane
• Re: Query much faster with enable_seqscan=0
  • From: Tom Lane
• Re: Auto ANALYZE criteria
  • From: Tom Lane
• Re: Using Between
  • From: Ozer, Pam
• Re: slow DDL creation
  • From: Robert Haas
• Re: Using Between
  • From: Robert Haas
• Re: Query much faster with enable_seqscan=0
  • From: Ogden
• Re: GPU Accelerated Sorting
  • From: Robert Haas
• Re: Query much faster with enable_seqscan=0
  • From: Greg Smith
• Re: Query much faster with enable_seqscan=0
  • From: Joshua D. Drake
• Re: Query much faster with enable_seqscan=0
  • From: Ogden
• Re: Query much faster with enable_seqscan=0
  • From: Jesper Krogh
• Re: Query much faster with enable_seqscan=0
  • From: Ogden
• Re: Query much faster with enable_seqscan=0
  • From: Kenneth Marshall
• Query much faster with enable_seqscan=0
  • From: Ogden
• Re: Auto ANALYZE criteria
  • From: Joe Miller
• Re: Auto ANALYZE criteria
  • From: Joe Miller
• Memory speed testing
  • From: Greg Smith
• Re: Auto ANALYZE criteria
  • From: Tom Lane
• Re: Auto ANALYZE criteria
  • From: Kevin Grittner
• Auto ANALYZE criteria
  • From: Joe Miller
• Re: 3ware trivia overload
  • From: David Rees
• Re: 3ware trivia overload
  • From: George Sexton
• Re: cleanup on pg_ system tables?
  • From: Josh Kupershmidt
• Need PostgreSQL data warehousing user, on the record
  • From: Josh Berkus
• cleanup on pg_ system tables?
  • From: mark
• Performance degradation, index bloat and planner estimates
  • From: Daniele Varrazzo
• 3ware trivia overload
  • From: Greg Smith
• Re: Where does data in pg_stat_user_tables come from?
  • From: Josh Berkus
• Re: Where does data in pg_stat_user_tables come from?
  • From: Tom Lane
• Re: Where does data in pg_stat_user_tables come from?
  • From: Guillaume Lelarge
• Re: Where does data in pg_stat_user_tables come from?
  • From: Josh Berkus
• Re: Performance problem with joined aggregate query
  • From: Merlin Moncure
• Re: Is disableing nested_loops a bad idea ?
  • From: Kevin Grittner
• Re: Performance problem with joined aggregate query
  • From: Anssi Kääriäinen
• Problem with mergejoin performance (some bug?)
  • From: azajac
• Re: Is disableing nested_loops a bad idea ?
  • From: Franck Routier
• Re: Is disableing nested_loops a bad idea ?
  • From: Kevin Grittner
• Re: Is disableing nested_loops a bad idea ?
  • From: Samuel Gendler
• Is disableing nested_loops a bad idea ?
  • From: Franck Routier
• Re: locking issue on simple selects?
  • From: Greg Smith
• Re: Performance problem with joined aggregate query
  • From: Merlin Moncure
• Re: locking issue on simple selects?
  • From: Tobias Brox
• Re: turn off caching for performance test
  • From: Merlin Moncure
• Re: locking issue on simple selects?
  • From: Brad Nicholson
• Re: locking issue on simple selects?
  • From: Greg Smith
• Re: locking issue on simple selects?
  • From: Tom Lane
• Re: locking issue on simple selects?
  • From: Tobias Brox
• Performance problem with joined aggregate query
  • From: Anssi Kääriäinen
• Re: Slow SQL lookup due to every field being listed in SORT KEY
  • From: Mason Harding
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: locking issue on simple selects?
  • From: Tom Lane
• Re: POSTGRES error
  • From: Kevin Grittner
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Merlin Moncure
• POSTGRES error
  • From: Timothy.Noonan
• locking issue on simple selects?
  • From: Tobias Brox
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Merlin Moncure
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Held idle connections vs use of a Pooler
  • From: Craig James
• Re: Useless sort by
  • From: Gaetano Mendola
• Re: Held idle connections vs use of a Pooler
  • From: Joshua D. Drake
• Re: Held idle connections vs use of a Pooler
  • From: Merlin Moncure
• Re: Useless sort by
  • From: Dave Crooke
• Held idle connections vs use of a Pooler
  • From: mark
• Re: Useless sort by
  • From: Maciek Sakrejda
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Merlin Moncure
• Re: Useless sort by
  • From: Heikki Linnakangas
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Where does data in pg_stat_user_tables come from?
  • From: Alvaro Herrera
• Re: Where does data in pg_stat_user_tables come from?
  • From: Tom Lane
• Re: Where does data in pg_stat_user_tables come from?
  • From: Josh Berkus
• Re: Where does data in pg_stat_user_tables come from?
  • From: Joshua D. Drake
• Re: Where does data in pg_stat_user_tables come from?
  • From: Josh Berkus
• Re: Where does data in pg_stat_user_tables come from?
  • From: Joshua D. Drake
• Where does data in pg_stat_user_tables come from?
  • From: Josh Berkus
• Re: Useless sort by
  • From: Scott Marlowe
• Re: Useless sort by
  • From: Maciek Sakrejda
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Merlin Moncure
• Re: Useless sort by
  • From: Gaetano Mendola
• Re: Useless sort by
  • From: Tom Lane
• Re: Useless sort by
  • From: Gaetano Mendola
• Re: Problem with mergejoin performance
  • From: Tom Lane
• Re: Useless sort by
  • From: Tom Lane
• Re: Problem with mergejoin performance
  • From: Tom Lane
• Useless sort by
  • From: Gaetano Mendola
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Problem with mergejoin performance
  • From: azajac
• Re: Slow SQL lookup due to every field being listed in SORT KEY
  • From: Stephen Frost
• Re: Slow SQL lookup due to every field being listed in SORT KEY
  • From: Tom Lane
• Re: Slow SQL lookup due to every field being listed in SORT KEY
  • From: Stephen Frost
• Slow SQL lookup due to every field being listed in SORT KEY
  • From: Mason Harding
• Re: pgbench could not send data to client: Broken pipe
  • From: Greg Smith
• Re: pgbench could not send data to client: Broken pipe
  • From: Kevin Grittner
• Re: pgbench could not send data to client: Broken pipe
  • From: Greg Smith
• Re: pgbench could not send data to client: Broken pipe
  • From: David Kerr
• Re: pgbench could not send data to client: Broken pipe
  • From: Alvaro Herrera
• Re: pgbench could not send data to client: Broken pipe
  • From: David Kerr
• Re: pgbench could not send data to client: Broken pipe
  • From: Kevin Grittner
• Re: pgbench could not send data to client: Broken pipe
  • From: David Kerr
• Re: pgbench could not send data to client: Broken pipe
  • From: Kevin Grittner
• Re: pgbench could not send data to client: Broken pipe
  • From: David Kerr
• Re: pgbench could not send data to client: Broken pipe
  • From: Kevin Grittner
• Re: pgbench could not send data to client: Broken pipe
  • From: David Kerr
• Re: pgbench could not send data to client: Broken pipe
  • From: Tom Lane
• Re: pgbench could not send data to client: Broken pipe
  • From: David Kerr
• Re: pgbench could not send data to client: Broken pipe
  • From: David Kerr
• Re: pgbench could not send data to client: Broken pipe
  • From: Tom Lane
• Re: pgbench could not send data to client: Broken pipe
  • From: Greg Smith
• Re: pgbench could not send data to client: Broken pipe
  • From: Tom Lane
• pgbench could not send data to client: Broken pipe
  • From: David Kerr
• Re: Question about LEFT JOIN and query plan
  • From: Kevin Grittner
• Re: Question about LEFT JOIN and query plan
  • From: Kevin Grittner
• Re: Question about LEFT JOIN and query plan
  • From: Kaloyan Iliev Iliev
• Re: Question about LEFT JOIN and query plan
  • From: Kaloyan Iliev Iliev
• Re: Question about LEFT JOIN and query plan
  • From: Kaloyan Iliev Iliev
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Tom Lane
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Tom Lane
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Tom Lane
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Question about LEFT JOIN and query plan
  • From: Kevin Grittner
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Tom Lane
• Re: Question about LEFT JOIN and query plan
  • From: Tom Lane
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Tom Lane
• Question about LEFT JOIN and query plan
  • From: Kaloyan Iliev Iliev
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Odd estimation issue with user-defined type
  • From: Florian Weimer
• Re: Odd estimation issue with user-defined type
  • From: Tom Lane
• Odd estimation issue with user-defined type
  • From: Florian Weimer
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Tom Lane
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Tom Lane
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Scott Marlowe
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Yeb Havinga
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Greg Smith
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Scott Marlowe
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Scott Marlowe
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Jose Ildefonso Camargo Tolosa
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Yeb Havinga
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Jose Ildefonso Camargo Tolosa
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Greg Smith
• Re: slow DDL creation
  • From: Kevin Kempter
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Yeb Havinga
• Re: GPU Accelerated Sorting
  • From: Tom Lane
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Jose Ildefonso Camargo Tolosa
• Re: GPU Accelerated Sorting
  • From: Scott Carey
• Re: slow DDL creation
  • From: David Fetter
• Re: slow DDL creation
  • From: bricklen
• Re: GPU Accelerated Sorting
  • From: David Boreham
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Greg Smith
• slow DDL creation
  • From: Kevin Kempter
• Re: GPU Accelerated Sorting
  • From: Chris Browne
• Re: GPU Accelerated Sorting
  • From: Jeff Davis
• Re: GPU Accelerated Sorting
  • From: David Boreham
• Re: GPU Accelerated Sorting
  • From: Scott Marlowe
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Clemens Eisserer
• Re: GPU Accelerated Sorting
  • From: Yeb Havinga
• Re: GPU Accelerated Sorting
  • From: Eliot Gable
• Re: Using Between
  • From: Ozer, Pam
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Tom Lane
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Tom Lane
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Jose Ildefonso Camargo Tolosa
• Re: [Fwd: postgres 8.4.1 number of connections]
  • From: Maria L. Wilson
• GPU Accelerated Sorting
  • From: Eliot Gable
• Re: GPU Accelerated Sorting
  • From: Gaël Le Mignot
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Greg Smith
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Greg Smith
• Re: GPU Accelerated Sorting
  • From: Greg Smith
• GPU Accelerated Sorting
  • From: Eliot Gable
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Yeb Havinga
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Scott Marlowe
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Scott Carey
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Pavel Stehule
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Yeb Havinga
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Pavel Stehule
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Scott Marlowe
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Andreas Kretschmer
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Scott Marlowe
• Major performance problem after upgrade from 8.3 to 8.4
  • From: Gerhard Wiesinger
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Greg Smith
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Greg Smith
• Re: array can be slow when joining?
  • From: Pavel Stehule
• array can be slow when joining?
  • From: Volodymyr Kostyrko
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Jose Ildefonso Camargo Tolosa
• Re: write barrier question
  • From: Cédric Villemain
• Re: Using Between
  • From: Craig James
• Using Between
  • From: Ozer, Pam
• Re: turn off caching for performance test
  • From: Scott Marlowe
• Re: Slow Query
  • From: Ozer, Pam
• Re: Slow Query
  • From: Greg Smith
• Re: turn off caching for performance test
  • From: Greg Smith
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Greg Smith
• Re: Slow Query
  • From: Kevin Grittner
• Re: turn off caching for performance test
  • From: Willy-Bas Loos
• Re: [Fwd: postgres 8.4.1 number of connections]
  • From: Magnus Hagander
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Scott Carey
• Re: [Fwd: postgres 8.4.1 number of connections]
  • From: Josh Berkus
• Re: Slow Query
  • From: Bob Lunney
• Re: Slow Query
  • From: Scott Marlowe
• Slow Query
  • From: Ozer, Pam
• Re: [Fwd: postgres 8.4.1 number of connections]
  • From: Scott Marlowe
• [Fwd: postgres 8.4.1 number of connections]
  • From: Maria L. Wilson
• Re: turn off caching for performance test
  • From: Pierre C
• Re: turn off caching for performance test
  • From: Arjen van der Meijden
• turn off caching for performance test
  • From: Willy-Bas Loos
• Re: SubQuery Performance
  • From: A. Kretschmer
• SubQuery Performance
  • From: mike
• Re: New servers, need suggestions for sensible tuning settings
  • From: Kevin Grittner
• New servers, need suggestions for sensible tuning settings
  • From: Bob Branch
• Re: Triggers or code?
  • From: Bob Lunney
• Re: Are Indices automatically generated for primary keys?
  • From: Guillaume Lelarge
• Re: Inefficient query plan
  • From: Jann Röder
• Re: Inefficient query plan
  • From: Jann Röder
• Re: PARSE WAITING
  • From: Alvaro Herrera
• Re: PARSE WAITING
  • From: David Kerr
• Re: PARSE WAITING
  • From: Alvaro Herrera
• Re: PARSE WAITING
  • From: David Kerr
• PARSE WAITING
  • From: David Kerr
• Re: Triggers or code?
  • From: André Fernandes
• Triggers or code?
  • From: DM
• Re: Inefficient query plan
  • From: Scott Marlowe
• Re: Inefficient query plan
  • From: gnuoytr
• Re: Inefficient query plan
  • From: Tom Lane
• Re: Inefficient query plan
  • From: Kevin Grittner
• Re: Inefficient query plan
  • From: Grzegorz Jaśkiewicz
• Re: Inefficient query plan
  • From: Grzegorz Jaśkiewicz
• Re: Inefficient query plan
  • From: Alvaro Herrera
• Re: Inefficient query plan
  • From: Kevin Grittner
• Re: Inefficient query plan
  • From: Grzegorz Jaśkiewicz
• Re: Inefficient query plan
  • From: Kevin Grittner
• Re: Inefficient query plan
  • From: Kevin Grittner
• Re: Inefficient query plan
  • From: Grzegorz Jaśkiewicz
• Re: Inefficient query plan
  • From: Jann Röder
• Re: Inefficient query plan
  • From: Kevin Grittner
• Re: Inefficient query plan
  • From: Kevin Grittner
• Re: Inefficient query plan
  • From: Jann Röder
• Re: Inefficient query plan
  • From: Scott Marlowe
• Re: Inefficient query plan
  • From: Jann Röder
• Re: Inefficient query plan
  • From: Scott Marlowe
• Re: Inefficient query plan
  • From: Scott Marlowe
• Inefficient query plan
  • From: Jann Röder
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Greg Smith
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Greg Smith
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Dimitri
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Robert Haas
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Alexandre de Arruda Paes
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Dimitri
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Scott Marlowe
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Dimitri
• Re: Copy performance issues
  • From: Sergey Konoplev
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Greg Smith
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Greg Smith
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Scott Marlowe
• Re: yet another q
  • From: Tom Lane
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Tom Lane
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Kevin Grittner
• Re: in-memory sorting
  • From: Tom Lane
• Re: Fwd: Vacuum Full + Cluster + Vacuum full = non removable dead rows
  • From: Alexandre de Arruda Paes
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Philippe Rimbault
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Philippe Rimbault
• Re: Performance on new 64bit server compared to my 32bit desktop
  • From: Scott Marlowe
• Performance on new 64bit server compared to my 32bit desktop
  • From: Philippe Rimbault
• Re: in-memory sorting
  • From: Scott Marlowe
• Re: in-memory sorting
  • From: Samuel Gendler
• Re: in-memory sorting
  • From: Samuel Gendler
• Re: in-memory sorting
  • From: Scott Marlowe
• Re: yet another q
  • From: Samuel Gendler
• Re: yet another q
  • From: Samuel Gendler
• Re: in-memory sorting
  • From: Samuel Gendler
• Re: in-memory sorting
  • From: Scott Marlowe
• yet another q
  • From: Samuel Gendler
• Re: in-memory sorting
  • From: Pavel Stehule
• Re: in-memory sorting
  • From: Samuel Gendler
• in-memory sorting
  • From: Samuel Gendler
• Re: Copy performance issues
  • From: s anwar
• Re: Copy performance issues
  • From: Greg Smith
• Re: Copy performance issues
  • From: Tom Lane
• Copy performance issues
  • From: Saadat Anwar
• Re: write barrier question
  • From: Samuel Gendler