Postgres Performance Date Index

• Thread Index

• Re: use pgsql in a big project, but i found pg has some big problem on concurrency write operation, maybe a joke for myself !
  • From: Kevin Grittner
• the jokes for pg concurrency write performance
  • From: wyx6fox
• use pgsql in a big project, but i found pg has some big problem on concurrency write operation, maybe a joke for myself !
  • From: wyx6fox
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: Slow query: table iteration (8.3)
  • From: Yeb Havinga
• Re: Constraint propagating for equal fields
  • From: Віталій Тимчишин
• Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: Constraint propagating for equal fields
  • From: Greg Stark
• Re: Limited Shared Buffer Problem
  • From: Greg Smith
• Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Stark
• Re: Limited Shared Buffer Problem
  • From: **Rod MacNeil
• Re: Limited Shared Buffer Problem
  • From: Cédric Villemain
• Re: Limited Shared Buffer Problem
  • From: jose javier parra sanchez
• Re: Limited Shared Buffer Problem
  • From: "Ing . Marcos Luís Ortíz Valmaseda"
• Re: Limited Shared Buffer Problem
  • From: Scott Marlowe
• Re: Limited Shared Buffer Problem
  • From: Richard Neill
• Limited Shared Buffer Problem
  • From: **Rod MacNeil
• Constraint propagating for equal fields
  • From: Віталій Тимчишин
• Re: Benchmark shows very slow bulk delete
  • From: Ivan Voras
• Re: Benchmark shows very slow bulk delete
  • From: Greg Smith
• Re: Benchmark shows very slow bulk delete
  • From: James Mansion
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Віталій Тимчишин
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Matthew Wakeling
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Віталій Тимчишин
• Re: Benchmark shows very slow bulk delete
  • From: Andres Freund
• Re: test send (recommended by Dave Page)
  • From: Dave Page
• Re: Benchmark shows very slow bulk delete
  • From: Nikolas Everett
• Re: test send (recommended by Dave Page)
  • From: Matthew Wakeling
• test send (recommended by Dave Page)
  • From: Mark Steben
• Re: Benchmark shows very slow bulk delete
  • From: Kevin Grittner
• Re: Benchmark shows very slow bulk delete
  • From: Matthew Wakeling
• Re: Benchmark shows very slow bulk delete
  • From: Ivan Voras
• Benchmark shows very slow bulk delete
  • From: Thom Brown
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Smith
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Greg Smith
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Greg Smith
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Scott Carey
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Scott Carey
• Re: Poor query plan across OR operator
  • From: Kevin Grittner
• Re: Poor query plan across OR operator
  • From: Tom Lane
• Re: splitting data into multiple tables
  • From: Greg Smith
• Re: Poor query plan across OR operator
  • From: Robert Haas
• Re: splitting data into multiple tables
  • From: Viji V Nair
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Richard Neill
• Re: splitting data into multiple tables
  • From: Greg Smith
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Matthew Wakeling
• Re: Should the optimiser convert a CASE into a WHERE if it can?
  • From: Tom Lane
• Should the optimiser convert a CASE into a WHERE if it can?
  • From: Richard Neill
• Re: Poor query plan across OR operator
  • From: Tom Lane
• Re: Poor query plan across OR operator
  • From: Grzegorz Jaśkiewicz
• Poor query plan across OR operator
  • From: Mark Hills
• Re: splitting data into multiple tables
  • From: nair rajiv
• Re: splitting data into multiple tables
  • From: Matthew Wakeling
• Re: splitting data into multiple tables
  • From: Matthew Wakeling
• Re: splitting data into multiple tables
  • From: Viji V Nair
• Re: splitting data into multiple tables
  • From: nair rajiv
• Re: splitting data into multiple tables
  • From: Andres Freund
• Re: splitting data into multiple tables
  • From: nair rajiv
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Tory M Blue
• Re: splitting data into multiple tables
  • From: Craig James
• Re: splitting data into multiple tables
  • From: Kevin Grittner
• Re: splitting data into multiple tables
  • From: Viji V Nair
• Re: splitting data into multiple tables
  • From: Amitabh Kant
• splitting data into multiple tables
  • From: nair rajiv
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Sql result b where condition
  • From: A. Kretschmer
• Re: Sql result b where condition
  • From: Matthew Wakeling
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Matthew Wakeling
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Richard Huxton
• Re: Sql result b where condition
  • From: A. Kretschmer
• Sql result b where condition
  • From: ramasubramanian
• Re: Fragmentation/Vacuum, Analyze, Re-Index
  • From: Reid Thompson
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Scott Carey
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Scott Carey
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Scott Carey
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Craig Ringer
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Fragmentation/Vacuum, Analyze, Re-Index
  • From: Richard Neill
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Tory M Blue
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Tory M Blue
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Scott Marlowe
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Matthew Wakeling
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Richard Huxton
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Tory M Blue
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Tory M Blue
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Carlo Stonebanks
• Re: Fragmentation/Vacuum, Analyze, Re-Index
  • From: DM
• Re: Slow update query
  • From: Robert Haas
• Slow update query
  • From: elias ghanem
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Richard Huxton
• Fragmentation/Vacuum, Analyze, Re-Index
  • From: DM
• Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Craig Ringer
• Re: Slow update query
  • From: Craig Ringer
• Re: ext4 finally doing the right thing
  • From: Greg Smith
• Re: TPC-C implementation for postgresql?
  • From: Greg Smith
• TPC-C implementation for postgresql?
  • From: tmp
• Re: performance question on VACUUM FULL (Postgres 8.4.2)
  • From: PG User 2010
• Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
  • From: Tory M Blue
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Devrim GÜNDÜZ
• Re: Slow update query
  • From: Kevin Grittner
• Slow update query
  • From: elias ghanem
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Scott Marlowe
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Alvaro Herrera
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Scott Marlowe
• Re: ext4 finally doing the right thing
  • From: Pierre Frédéric Caillaud
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Florian Weimer
• Re: ext4 finally doing the right thing
  • From: Kevin Grittner
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Alvaro Herrera
• Re: Slow update query
  • From: Kevin Grittner
• Slow update query
  • From: elias ghanem
• Re: ext4 finally doing the right thing
  • From: Aidan Van Dyk
• Re: ext4 finally doing the right thing
  • From: Greg Smith
• Re: ext4 finally doing the right thing
  • From: Florian Weimer
• Re: ext4 finally doing the right thing
  • From: Aidan Van Dyk
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Matthew Wakeling
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Matthew Wakeling
• Re: ext4 finally doing the right thing
  • From: Greg Stark
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Greg Smith
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Scott Carey
• Re: ext4 finally doing the right thing
  • From: Greg Smith
• Re: ext4 finally doing the right thing
  • From: Greg Stark
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Robert Haas
• Re: Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Carlo Stonebanks
• Re: ext4 finally doing the right thing
  • From: Greg Smith
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Kevin Grittner
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Carlo Stonebanks
• Re: Change query join order
  • From: Kaloyan Iliev Iliev
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Matthew Wakeling
• Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Smith
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: renice on an I/O bound box
  • From: Craig Ringer
• Re: ext4 finally doing the right thing
  • From: Jeff Davis
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Scott Marlowe
• Re: performance question on VACUUM FULL (Postgres 8.4.2)
  • From: Jeff Davis
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Carlo Stonebanks
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Scott Carey
• performance question on VACUUM FULL (Postgres 8.4.2)
  • From: PG User 2010
• Re: renice on an I/O bound box
  • From: Arjen van der Meijden
• Re: renice on an I/O bound box
  • From: Willy-Bas Loos
• Re: renice on an I/O bound box
  • From: Ing. Marcos L. Ortiz Valmaseda
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Ivan Voras
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Tom Lane
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Kevin Grittner
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Stark
• Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Stark
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• renice on an I/O bound box
  • From: Willy-Bas Loos
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Richard Huxton
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Ivan Voras
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Scott Carey
• Re: Bad plan choice nestloop vs. hashjoin
  • From: Kenneth Marshall
• Re: Bad plan choice nestloop vs. hashjoin
  • From: Tom Lane
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Stark
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Tom Lane
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Pierre Frédéric Caillaud
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Robert Haas
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Tom Lane
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Craig Ringer
• ext4 finally doing the right thing
  • From: Greg Smith
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Greg Smith
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Tom Lane
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Dave Crooke
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Dave Crooke
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: Bad plan choice nestloop vs. hashjoin
  • From: Tom Lane
• Re: Bad plan choice nestloop vs. hashjoin
  • From: Kenneth Marshall
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Dave Crooke
• Re: Bad plan choice nestloop vs. hashjoin
  • From: Kevin Grittner
• Bad plan choice nestloop vs. hashjoin
  • From: Kenneth Marshall
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Kevin Grittner
• Re: new server I/O setup
  • From: Scott Marlowe
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Scott Marlowe
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Merlin Moncure
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: new server I/O setup
  • From: Fernando Hevia
• Re: new server I/O setup
  • From: Fernando Hevia
• Re: Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Ing. Marcos L. Ortiz Valmaseda
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Greg Smith
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: new server I/O setup
  • From: Pierre Frédéric Caillaud
• Re: Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Robert Haas
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Matthew Wakeling
• Re: OT: Db2 connection pooling?
  • From: Alan McKay
• OT: Db2 connection pooling?
  • From: Alan McKay
• Re: new server I/O setup
  • From: Matthew Wakeling
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Craig James
• Re: new server I/O setup
  • From: Fernando Hevia
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Tom Lane
• Re: new server I/O setup
  • From: Fernando Hevia
• Re: New server to improve performance on our large and busy DB - advice?
  • From: marcin mank
• Re: Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Pierre Frédéric Caillaud
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Ivan Voras
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Robert Haas
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Richard Broersma
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Tony McC
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Matthew Wakeling
• Re: new server I/O setup
  • From: Matthew Wakeling
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Matthew Wakeling
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Matthew Wakeling
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Pierre Frédéric Caillaud
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Florian Weimer
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Carlo Stonebanks
• Re: new server I/O setup
  • From: Greg Smith
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Magnus Hagander
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Greg Smith
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Craig Ringer
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Pierre Frédéric Caillaud
• Re: New server to improve performance on our large and busy DB - advice? (v2)
  • From: Dave Crooke
• Re: Massive table (500M rows) update nightmare
  • From: Carlo Stonebanks
• New server to improve performance on our large and busy DB - advice? (v2)
  • From: Carlo Stonebanks
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Scott Marlowe
• Re: Massive table (500M rows) update nightmare
  • From: Craig James
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Fernando Hevia
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: new server I/O setup
  • From: Scott Marlowe
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• new server I/O setup
  • From: Fernando Hevia
• Re: New server to improve performance on our large and busy DB - advice?
  • From: Joshua D. Drake
• Re: Massive table (500M rows) update nightmare
  • From: Carlo Stonebanks
• New server to improve performance on our large and busy DB - advice?
  • From: Carlo Stonebanks
• Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: Greg Smith
• Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: Kevin Grittner
• Re: bad execution plan for subselects containing windowing-function
  • From: Andreas Kretschmer
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: Greg Smith
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Andy Colson
• Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: Kevin Grittner
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: bad execution plan for subselects containing windowing-function
  • From: Andreas Kretschmer
• Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: Greg Smith
• Re: bad execution plan for subselects containing windowing-function
  • From: Tom Lane
• Re: bad execution plan for subselects containing windowing-function
  • From: Andreas Kretschmer
• Re: bad execution plan for subselects containing windowing-function
  • From: Tom Lane
• bad execution plan for subselects containing windowing-function
  • From: Andreas Kretschmer
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Pierre Frédéric Caillaud
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Pierre Frédéric Caillaud
• Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: Kevin Grittner
• Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: Ivan Voras
• Re: performance config help
  • From: Pierre Frédéric Caillaud
• Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: Kevin Grittner
• Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: A. Kretschmer
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Florian Weimer
• Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: Matthew Wakeling
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Aidan Van Dyk
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Matthew Wakeling
• Slow "Select count(*) ..." query on table with 60 Mio. rows
  • From: tom
• Re: Inserting 8MB bytea: just 25% of disk perf used?
  • From: Ivan Voras
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Andy Colson
• Inserting 8MB bytea: just 25% of disk perf used?
  • From: fkater@xxxxxxxxxxxxxx
• Re: performance config help
  • From: Dimitri Fontaine
• Re: performance config help
  • From: Craig Ringer
• Re: performance config help
  • From: Craig Ringer
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Craig Ringer
• Re: performance config help
  • From: Bob Dusek
• Re: Hashaggregate estimates
  • From: Tom Lane
• Hashaggregate estimates
  • From: Jorge Montero
• Re: performance config help
  • From: Scott Marlowe
• Re: performance config help
  • From: Bob Dusek
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Scott Marlowe
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Robert Haas
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Tom Lane
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Scott Marlowe
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Robert Haas
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Robert Haas
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Jaime Casanova
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Robert Haas
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Tom Lane
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Robert Haas
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Tom Lane
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Euler Taveira de Oliveira
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Craig Ringer
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Greg Smith
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Jaime Casanova
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Craig Ringer
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Craig Ringer
• Re: a heavy duty operation on an "unused" table kills my server
  • From: Craig James
• Re: performance config help
  • From: Craig Ringer
• a heavy duty operation on an "unused" table kills my server
  • From: Eduardo Piombino
• Re: performance config help
  • From: Matthew Wakeling
• Re: performance config help
  • From: Bob Dusek
• Re: performance config help
  • From: Bob Dusek
• Re: performance config help
  • From: Kevin Grittner
• Re: performance config help
  • From: Matthew Wakeling
• Re: performance config help
  • From: Pierre Frédéric Caillaud
• Re: performance config help
  • From: Scott Marlowe
• Re: performance config help
  • From: Greg Smith
• Re: performance config help
  • From: Scott Marlowe
• Re: Choice of bitmap scan over index scan
  • From: Robert Haas
• Re: performance config help
  • From: Greg Smith
• Re: performance config help
  • From: Dusek, Bob
• Re: performance config help
  • From: Greg Smith
• Re: performance config help
  • From: Kevin Grittner
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Tom Lane
• Re: performance config help
  • From: Bob Dusek
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Jaime Casanova
• Re: performance config help
  • From: Kevin Grittner
• Re: performance config help
  • From: Tom Lane
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Tom Lane
• Re: performance config help
  • From: Scott Marlowe
• Re: performance config help
  • From: Dusek, Bob
• Re: performance config help
  • From: Scott Marlowe
• Re: Choice of bitmap scan over index scan
  • From: Jeremy Harris
• Re: performance config help
  • From: Scott Marlowe
• Re: performance config help
  • From: Scott Marlowe
• Re: performance config help
  • From: Bob Dusek
• Re: performance config help
  • From: Scott Marlowe
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Jaime Casanova
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Jaime Casanova
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Robert Haas
• Re: performance config help
  • From: Bob Dusek
• Re: performance config help
  • From: Kevin Grittner
• Re: performance config help
  • From: Scott Marlowe
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Jaime Casanova
• Re: performance config help
  • From: Bob Dusek
• Re: performance config help
  • From: Bob Dusek
• Re: performance config help
  • From: Scott Marlowe
• Re: performance config help
  • From: Scott Marlowe
• cache false-sharing in lwlocks
  • From: Rayson Ho
• Re: performance config help
  • From: Ivan Voras
• Re: performance config help
  • From: Kevin Grittner
• Re: performance config help
  • From: Ivan Voras
• Re: performance config help
  • From: Bob Dusek
• Re: performance config help
  • From: Bob Dusek
• Re: Choice of bitmap scan over index scan
  • From: Kevin Grittner
• Re: performance config help
  • From: A. Kretschmer
• Re: performance config help
  • From: Scott Marlowe
• performance config help
  • From: Bob Dusek
• Re: PG optimization question
  • From: Pierre Frédéric Caillaud
• Re: Choice of bitmap scan over index scan
  • From: Pierre Frédéric Caillaud
• Re: Choice of bitmap scan over index scan
  • From: Matthew Wakeling
• Re: Choice of bitmap scan over index scan
  • From: Mathieu De Zutter
• Re: Choice of bitmap scan over index scan
  • From: Robert Haas
• Re: Choice of bitmap scan over index scan
  • From: Robert Haas
• Re: PG optimization question
  • From: Robert Haas
• Re: Choice of bitmap scan over index scan
  • From: Kevin Grittner
• Re: Choice of bitmap scan over index scan
  • From: Kevin Grittner
• Re: Choice of bitmap scan over index scan
  • From: Mathieu De Zutter
• Re: Choice of bitmap scan over index scan
  • From: Kevin Grittner
• Re: Choice of bitmap scan over index scan
  • From: Jeremy Harris
• Choice of bitmap scan over index scan
  • From: Mathieu De Zutter
• Re: PG optimization question
  • From: Pierre Frédéric Caillaud
• Re: PG optimization question
  • From: Craig Ringer
• Re: PG optimization question
  • From: Ludwik Dylag
• Re: PG optimization question
  • From: Nickolay
• Re: Joint index including MAX() ?
  • From: Tom Lane
• Re: pg_connect takes 3.0 seconds
  • From: Dmitri Girski
• Re: PG optimization question
  • From: Pierre Frédéric Caillaud
• Re: PG optimization question
  • From: Nickolay
• Re: Joint index including MAX() ?
  • From: Lefteris
• Re: Joint index including MAX() ?
  • From: Grzegorz Jaśkiewicz
• Re: PG optimization question
  • From: Kenneth Marshall
• Joint index including MAX() ?
  • From: Richard Neill
• Re: PG optimization question
  • From: Nickolay
• Re: PG optimization question
  • From: Thomas Kellerer
• Re: PG optimization question
  • From: Grzegorz Jaśkiewicz
• PG optimization question
  • From: Nickolay
• PG optimization question
  • From: Nickolay
• Re: Massive table (500M rows) update nightmare
  • From: Pierre Frédéric Caillaud
• Re: Change query join order
  • From: Robert Haas
• Re: Change query join order
  • From: Tom Lane
• Re: Change query join order
  • From: Robert Haas
• Re: Change query join order
  • From: Tom Lane
• Re: Massive table (500M rows) update nightmare
  • From: Kevin Grittner
• Re: Massive table (500M rows) update nightmare
  • From: Greg Smith
• Change query join order
  • From: Kaloyan Iliev Iliev
• Re: Massive table (500M rows) update nightmare
  • From: Kenneth Marshall
• Re: Massive table (500M rows) update nightmare
  • From: Carlo Stonebanks
• Re: Massive table (500M rows) update nightmare
  • From: Andreas Kretschmer
• Re: Massive table (500M rows) update nightmare
  • From: Carlo Stonebanks
• Re: Array comparison
  • From: Merlin Moncure
• Re: Array comparison
  • From: Rui Carvalho
• Re: Massive table (500M rows) update nightmare
  • From: Kevin Grittner
• Re: Massive table (500M rows) update nightmare
  • From: Eduardo Morras
• FusionIO performance
  • From: Tore Halvorsen
• Re: Massive table (500M rows) update nightmare
  • From: Scott Marlowe
• Re: Massive table (500M rows) update nightmare
  • From: Carlo Stonebanks
• Re: Massive table (500M rows) update nightmare
  • From: Carlo Stonebanks
• Array comparison
  • From: ramasubramanian
• Re: Air-traffic benchmark
  • From: Craig Ringer
• Re: Air-traffic benchmark
  • From: Tom Lane
• Re: Air-traffic benchmark
  • From: Craig Ringer
• Re: "large" spam tables and performance: postgres memory parameters
  • From: Stephen Frost
• Re: "large" spam tables and performance: postgres memory parameters
  • From: Scott Marlowe
• Re: Massive table (500M rows) update nightmare
  • From: Scott Marlowe
• Re: Air-traffic benchmark
  • From: Greg Smith
• Re: Massive table (500M rows) update nightmare
  • From: Kevin Grittner
• Re: Air-traffic benchmark
  • From: hubert depesz lubaczewski
• Re: Air-traffic benchmark
  • From: Lefteris
• Re: Air-traffic benchmark
  • From: Lefteris
• Re: Air-traffic benchmark
  • From: Greg Smith
• Re: Massive table (500M rows) update nightmare
  • From: Carlo Stonebanks
• Re: Massive table (500M rows) update nightmare
  • From: marcin mank
• Re: noob inheritance question
  • From: Robert Haas
• Re: query looping?
  • From: Robert Haas
• Re: pg_connect takes 3.0 seconds
  • From: Dave Crooke
• Re: Joining on text field VS int
  • From: Nikolas Everett
• Re: query looping?
  • From: Brian Cox
• Re: Massive table (500M rows) update nightmare
  • From: Carlo Stonebanks
• Re: Massive table (500M rows) update nightmare
  • From: Carlo Stonebanks
• Re: Air-traffic benchmark
  • From: Nikolas Everett
• Re: Air-traffic benchmark
  • From: Gurgel, Flavio
• Re: Air-traffic benchmark
  • From: Scott Marlowe
• Re: Air-traffic benchmark
  • From: Gurgel, Flavio
• Re: Massive table (500M rows) update nightmare
  • From: Greg Sabino Mullane
• Re: Massive table (500M rows) update nightmare
  • From: Kevin Kempter
• Re: "large" spam tables and performance: postgres memory parameters
  • From: Kevin Grittner
• Re: Massive table (500M rows) update nightmare
  • From: Kevin Grittner
• Re: Massive table (500M rows) update nightmare
  • From: Ludwik Dylag
• Re: Air-traffic benchmark
  • From: Craig James
• Re: Air-traffic benchmark
  • From: Matthew Wakeling
• Re: Air-traffic benchmark
  • From: Lefteris
• Re: Air-traffic benchmark
  • From: Ivan Voras
• "large" spam tables and performance: postgres memory parameters
  • From: Gary Warner
• Re: Massive table (500M rows) update nightmare
  • From: Leo Mannhart
• Re: Air-traffic benchmark
  • From: Gurgel, Flavio
• Re: Massive table (500M rows) update nightmare
  • From: Kevin Grittner
• Re: Air-traffic benchmark
  • From: Grzegorz Jaśkiewicz
• Re: Air-traffic benchmark
  • From: Lefteris
• Re: Air-traffic benchmark
  • From: Ivan Voras
• Re: Air-traffic benchmark
  • From: Jochen Erwied
• Re: Air-traffic benchmark
  • From: Lefteris
• Re: Air-traffic benchmark
  • From: Alvaro Herrera
• Re: Air-traffic benchmark
  • From: Alvaro Herrera
• Re: Air-traffic benchmark
  • From: Lefteris
• Re: Air-traffic benchmark
  • From: A. Kretschmer
• Re: Air-traffic benchmark
  • From: A. Kretschmer
• Re: Air-traffic benchmark
  • From: Lefteris
• Re: Air-traffic benchmark
  • From: Arjen van der Meijden
• Re: Air-traffic benchmark
  • From: Lefteris
• Re: Massive table (500M rows) update nightmare
  • From: Leo Mannhart
• Re: Air-traffic benchmark
  • From: A. Kretschmer
• Re: Air-traffic benchmark
  • From: Gurgel, Flavio
• Air-traffic benchmark
  • From: Lefteris
• Re: Digesting explain analyze
  • From: Matthew Wakeling
• Re: Digesting explain analyze
  • From: Oleg Bartunov
• Re: Massive table (500M rows) update nightmare
  • From: Scott Marlowe
• Re: Optimizer use of index slows down query by factor
  • From: Michael Ruf
• Massive table (500M rows) update nightmare
  • From: Carlo Stonebanks
• Re: pg_connect takes 3.0 seconds
  • From: Craig Ringer
• Re: Digesting explain analyze
  • From: Greg Smith
• Re: Digesting explain analyze
  • From: Jesper Krogh
• Joining on text field VS int
  • From: Radhika S
• Re: noob inheritance question
  • From: Nikolas Everett
• Re: pg_connect takes 3.0 seconds
  • From: Scott Marlowe
• Re: pg_connect takes 3.0 seconds
  • From: Dmitri Girski
• Re: Digesting explain analyze
  • From: Robert Haas
• Re: noob inheritance question
  • From: Richard Neill
• Re: noob inheritance question
  • From: Richard Broersma
• noob inheritance question
  • From: Zintrigue
• Re: pg_connect takes 3.0 seconds
  • From: Robert Haas
• Re: pg_connect takes 3.0 seconds
  • From: Dave Crooke
• Re: Digesting explain analyze
  • From: Ron Mayer
• Digesting explain analyze
  • From: Jesper Krogh
• Re: pg_connect takes 3.0 seconds
  • From: Craig James
• Re: pg_connect takes 3.0 seconds
  • From: Matthew Wakeling
• Re: pg_connect takes 3.0 seconds
  • From: Craig Ringer
• Re: pg_connect takes 3.0 seconds
  • From: Scott Marlowe
• Re: pg_connect takes 3.0 seconds
  • From: Dmitri Girski
• Re: pg_connect takes 3.0 seconds
  • From: Dmitri Girski
• Re: pg_connect takes 3.0 seconds
  • From: Dmitri Girski
• Re: pg_connect takes 3.0 seconds
  • From: Dmitri Girski
• Re: pg_connect takes 3.0 seconds
  • From: Dmitri Girski
• Re: query looping?
  • From: Robert Haas
• Re: DB is slow until DB is reloaded
  • From: Craig Ringer
• Re: DB is slow until DB is reloaded
  • From: Scott Carey
• Re: pg_connect takes 3.0 seconds
  • From: Scott Carey
• Re: query looping?
  • From: Brian Cox
• Re: query looping?
  • From: Brian Cox
• Re: forced sequential scan when condition has current_user
  • From: Keresztury Balázs
• Re: query looping?
  • From: Robert Haas
• Re: pg_connect takes 3.0 seconds
  • From: Andy Colson
• Re: forced sequential scan when condition has current_user
  • From: Fernando Hevia
• Re: DB is slow until DB is reloaded
  • From: Brad Nicholson
• Re: forced sequential scan when condition has current_user
  • From: Tom Lane
• Re: pg_connect takes 3.0 seconds
  • From: Tom Lane
• Re: DB is slow until DB is reloaded
  • From: Craig James
• Re: pg_connect takes 3.0 seconds
  • From: Greg Smith
• Re: forced sequential scan when condition has current_user
  • From: Craig Ringer
• pg_connect takes 3.0 seconds
  • From: Dmitri Girski
• Re: forced sequential scan when condition has current_user
  • From: Robert Haas
• Re: DB is slow until DB is reloaded
  • From: Steve Crawford
• Re: DB is slow until DB is reloaded
  • From: Madison Kelly
• Re: DB is slow until DB is reloaded
  • From: Madison Kelly
• Re: forced sequential scan when condition has current_user
  • From: Erik Jones
• Re: DB is slow until DB is reloaded
  • From: Scott Marlowe
• Re: forced sequential scan when condition has current_user
  • From: Keresztury Balázs
• Re: query looping?
  • From: Brian Cox
• Re: DB is slow until DB is reloaded
  • From: Greg Smith
• Re: DB is slow until DB is reloaded
  • From: Rosser Schwarz
• Re: forced sequential scan when condition has current_user
  • From: Robert Haas
• Re: DB is slow until DB is reloaded
  • From: Madison Kelly
• Re: DB is slow until DB is reloaded
  • From: Madison Kelly
• Re: DB is slow until DB is reloaded
  • From: Steve Crawford
• Re: query looping?
  • From: Robert Haas
• forced sequential scan when condition has current_user
  • From: Keresztury Balázs
• Re: DB is slow until DB is reloaded
  • From: Steve Crawford
• Re: DB is slow until DB is reloaded
  • From: Madison Kelly
• Re: DB is slow until DB is reloaded
  • From: Madison Kelly
• Re: DB is slow until DB is reloaded
  • From: Kevin Grittner
• Re: DB is slow until DB is reloaded
  • From: Brad Nicholson
• Re: DB is slow until DB is reloaded
  • From: Madison Kelly
• Re: DB is slow until DB is reloaded
  • From: Gary Doades
• Re: DB is slow until DB is reloaded
  • From: Richard Neill
• Re: DB is slow until DB is reloaded
  • From: Madison Kelly
• query looping?
  • From: Brian Cox
• Re: DB is slow until DB is reloaded
  • From: Steve Crawford
• Re: DB is slow until DB is reloaded
  • From: Gary Doades
• DB is slow until DB is reloaded
  • From: Madison Kelly
• Re: Message queue table - strange performance drop with changing limit size.
  • From: Greg Smith
• Re: Message queue table - strange performance drop with changing limit size.
  • From: Dimitri Fontaine
• Re: Message queue table - strange performance drop with changing limit size.
  • From: Jesper Krogh
• Re: Message queue table - strange performance drop with changing limit size.
  • From: Greg Williamson
• Message queue table - strange performance drop with changing limit size.
  • From: Jesper Krogh
• Re: Performance with partitions/inheritance and multiple tables
  • From: Anj Adu
• Re:
  • From: roopasatish
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Stark
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Michael Clemmons
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Michael Clemmons
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Smith
• Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: david
• Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: david
• Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Stark
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Thomas Kellerer
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Tom Lane
• Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: SATA drives performance
  • From: Craig James
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Tom Lane
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Kevin Grittner
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Tom Lane
• Re: SATA drives performance
  • From: Glyn Astill
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Kevin Grittner
• Re: SATA drives performance
  • From: Scott Marlowe
• Re: SATA drives performance
  • From: Richard Neill
• Re: SATA drives performance
  • From: Scott Marlowe
• Re: SATA drives performance
  • From: Richard Neill
• Re: SATA drives performance
  • From: Adam Tauno Williams
• Re: SATA drives performance
  • From: Ognjen Blagojevic
• Re: SATA drives performance
  • From: Scott Marlowe
• Re: SATA drives performance
  • From: Richard Neill
• Re: SATA drives performance
  • From: Jeremy Harris
• Re: SATA drives performance
  • From: Richard Neill
• Re: SATA drives performance
  • From: Greg Smith
• Re: SATA drives performance
  • From: Mark Mielke
• Re: SATA drives performance
  • From: Greg Smith
• Re: SATA drives performance
  • From: Gaël Le Mignot
• Re: Multicolumn index - WHERE ... ORDER BY
  • From: Tom Lane
• Re: SATA drives performance
  • From: Greg Smith
• Re: Performance with partitions/inheritance and multiple tables
  • From: Shrirang Chitnis
• Re: Optimizer use of index slows down query by factor
  • From: Tom Lane
• Re: SATA drives performance
  • From: Richard Neill
• Re: SATA drives performance
  • From: Scott Marlowe
• Performance with partitions/inheritance and multiple tables
  • From: Radhika S
• SATA drives performance
  • From: Ognjen Blagojevic
• Multicolumn index - WHERE ... ORDER BY
  • From: Lucas Maystre
• Optimizer use of index slows down query by factor
  • From: Michael Ruf
• Re: FSM - per database or per installation?
  • From: Craig Ringer
• Re: FSM - per database or per installation?
  • From: Alvaro Herrera
• Re: FSM - per database or per installation?
  • From: Scott Marlowe
• Re: FSM - per database or per installation?
  • From: Craig James
• Re: hardware priority for an SSD database?
  • From: Greg Smith
• hardware priority for an SSD database?
  • From: Ben Chobot
• Re: Idea how to get rid of Bitmap Heap Scan
  • From: Robert Haas
• Re: Idea how to get rid of Bitmap Heap Scan
  • From: Tom Lane
• Re: Idea how to get rid of Bitmap Heap Scan
  • From: Greg Stark
• Re: Idea how to get rid of Bitmap Heap Scan
  • From: Robert Haas
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Robert Haas
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Tom Lane
• Re: Issues with \copy from file
  • From: Robert Haas
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Robert Haas
• Re: Idea how to get rid of Bitmap Heap Scan
  • From: Greg Stark
• Re: Idea how to get rid of Bitmap Heap Scan
  • From: Michael N. Mikhulya
• Re: Issues with \copy from file
  • From: Sigurgeir Gunnarsson
• Re: Idea how to get rid of Bitmap Heap Scan
  • From: Matthew Wakeling
• Idea how to get rid of Bitmap Heap Scan
  • From: Michael N. Mikhulya
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Grzegorz Jaśkiewicz
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Robert Haas
• Re: Issues with \copy from file
  • From: Robert Haas
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Grzegorz Jaśkiewicz
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Robert Haas
• Re: Issues with \copy from file
  • From: Sigurgeir Gunnarsson
• Re: seq scan instead of index scan
  • From: Tom Lane
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Craig Ringer
• Re: seq scan instead of index scan
  • From: Scott Marlowe
• Re: seq scan instead of index scan
  • From: Karl Larsson
• Re: seq scan instead of index scan
  • From: Scott Marlowe
• Re: seq scan instead of index scan
  • From: Karl Larsson
• Re: seq scan instead of index scan
  • From: Scott Marlowe
• Re: seq scan instead of index scan
  • From: Greg Smith
• Re: seq scan instead of index scan
  • From: Karl Larsson
• Re: seq scan instead of index scan
  • From: Kevin Grittner
• Re: seq scan instead of index scan
  • From: Scott Marlowe
• seq scan instead of index scan
  • From: Karl Larsson
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Grzegorz Jaśkiewicz
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Robert Haas
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Tom Lane
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Thomas Hamilton
• Re: Automatic optimization of IN clauses via INNER JOIN
  • From: Tom Lane
• Automatic optimization of IN clauses via INNER JOIN
  • From: Thomas Hamilton
• Re: Parallel Function calls using multiple processes
  • From: Pavel Stehule
• Re: Parallel Function calls using multiple processes
  • From: Vishal Gupta
• Re: Parallel Function calls using multiple processes
  • From: Pavel Stehule
• Parallel Function calls using multiple processes
  • From: Vishal Gupta
• Re: big select is resulting in a large amount of disk writing by kjournald
  • From: Scott Carey
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Robert Haas
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Andres Freund
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Michael Clemmons
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Andres Freund
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Scott Marlowe
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Michael Clemmons
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Greg Smith
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Scott Marlowe
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Scott Carey
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Scott Marlowe
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Scott Mead
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Scott Marlowe
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Nikolas Everett
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Joshua D. Drake
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Nikolas Everett
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Joshua D. Drake
• Re: Load experimentation
  • From: Scott Carey
• Re: 8.4.1 ubuntu karmic slow createdb
  • From: Nikolas Everett
• Re: Load experimentation
  • From: Scott Carey