Postgres Performance Date Index

• Thread Index

• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Alvaro Herrera
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Tom Lane
• Re: Dell PERC H700/H800
  • From: Dave Crooke
• Re: Questions on plan with INSERT/SELECT on partitioned table
  • From: Tom Lane
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Kevin Grittner
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Karl Denninger
• Questions on plan with INSERT/SELECT on partitioned table
  • From: Connors, Bill
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Kevin Grittner
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Karl Denninger
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Kevin Grittner
• Re: Almost infinite query -> Different Query Plan when changing where clause value
  • From: Kevin Grittner
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Alvaro Herrera
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Alvaro Herrera
• Almost infinite query -> Different Query Plan when changing where clause value
  • From: lionel duboeuf
• Re: Immutable table functions
  • From: Yeb Havinga
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Immutable table functions
  • From: Luiz Angelo Daros de Luca
• Re: Dell PERC H700/H800
  • From: Scott Marlowe
• Re: Dell PERC H700/H800
  • From: Łukasz Jagiełło
• Re: Dell PERC H700/H800
  • From: James Mansion
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Aidan Van Dyk
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Alvaro Herrera
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: Dell PERC H700/H800
  • From: Scott Marlowe
• Re: Dell PERC H700/H800
  • From: Joshua D. Drake
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Scott Marlowe
• Re: perf problem with huge table
  • From: Leo Mannhart
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Robert Haas
• Dell PERC H700/H800
  • From: Matthew Wakeling
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Bruce Momjian
• Re: perf problem with huge table
  • From: jesper
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Tom Lane
• Re: How exactly PostgreSQL allocates memory for its needs?
  • From: Scott Marlowe
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: david
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: perf problem with huge table
  • From: Greg Smith
• Re: perf problem with huge table
  • From: Dave Crooke
• Re: perf problem with huge table
  • From: Jon Lewison
• Re: perf problem with huge table
  • From: Dave Crooke
• Re: perf problem with huge table
  • From: Jon Lewison
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Jorge Montero
• Re: perf problem with huge table
  • From: Dave Crooke
• Re: perf problem with huge table
  • From: Justin Graf
• perf problem with huge table
  • From: rama
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Robert Haas
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Scott Carey
• Re: Deferred constraint and delete performance
  • From: Andres Freund
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Jeff
• Re: How exactly PostgreSQL allocates memory for its needs?
  • From: Justin Graf
• Re: PostgreSQL - case studies
  • From: Stephen Frost
• Re: PostgreSQL - case studies
  • From: Kevin Grittner
• Re: [GENERAL] PostgreSQL - case studies
  • From: Ing. Marcos L. Ortiz Valmaseda
• Re: Deferred constraint and delete performance
  • From: Tom Lane
• Deferred constraint and delete performance
  • From: Franck Routier
• Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Pavel Stehule
• Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Scott Marlowe
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: [GENERAL] PostgreSQL - case studies
  • From: Scott Marlowe
• How exactly PostgreSQL allocates memory for its needs?
  • From: Anton Maksimenkov
• Re: PostgreSQL - case studies
  • From: Amitabh Kant
• 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
  • From: Bryce Nesbitt
• PostgreSQL - case studies
  • From: Jayadevan M
• Re: DISTINCT vs. GROUP BY
  • From: Dimi Paun
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Jeff
• Re: DISTINCT vs. GROUP BY
  • From: Tom Lane
• Re: DISTINCT vs. GROUP BY
  • From: Thom Brown
• DISTINCT vs. GROUP BY
  • From: Dimi Paun
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Amitabh Kant
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: moving pg_xlog -- yeah, it's worth it!
  • From: Jesper Krogh
• moving pg_xlog -- yeah, it's worth it!
  • From: Kevin Grittner
• Re: foreign key constraint lock behavour in postgresql
  • From: Albe Laurenz
• Re: [GENERAL] index is not using
  • From: Scott Marlowe
• Re: [GENERAL] index is not using
  • From: Guillaume Lelarge
• Re: index is not using?
  • From: Scott Marlowe
• index is not using?
  • From: AI Rumman
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: david
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Scott Carey
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Mark Wong
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Scott Marlowe
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Stark
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Josh Berkus
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Kevin Grittner
• Re: Linux I/O tuning: CFQ vs. deadline
  • From: Albe Laurenz
• Linux I/O tuning: CFQ vs. deadline
  • From: Greg Smith
• Re: foreign key constraint lock behavour in postgresql
  • From: Albe Laurenz
• Re: [HACKERS] 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: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Alvaro Herrera
• Re: [HACKERS] 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: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Tom Lane
• Re: [HACKERS] 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: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Re: Slow query: table iteration (8.3)
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Greg Smith
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: index on partitioned table
  • From: Robert Haas
• Re: foreign key constraint lock behavour in postgresql
  • From: Robert Haas
• Re: index on partitioned table
  • From: Nikolas Everett
• index on partitioned table
  • From: Wojtek
• Re: Slow query: table iteration (8.3)
  • From: Yeb Havinga
• Re: foreign key constraint lock behavour in postgresql
  • From: Albe Laurenz
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: foreign key constraint lock behavour in postgresql
  • From: Robert Haas
• Re: Slow-ish Query Needs Some Love
  • From: Robert Haas
• Re: Slow query: table iteration (8.3)
  • From: Robert Haas
• Re: bigint integers up to 19 digits.
  • From: Alvaro Herrera
• Re: bigint integers up to 19 digits.
  • From: Jochen Erwied
• Re: bigint integers up to 19 digits.
  • From: Tory M Blue
• Re: bigint integers up to 19 digits.
  • From: Alvaro Herrera
• Re: bigint integers up to 19 digits.
  • From: Craig James
• bigint integers up to 19 digits.
  • From: Tory M Blue
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Matthew Wakeling
• Re: Air-traffic benchmark
  • From: Simon Riggs
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Ivan Voras
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: Slow query: table iteration (8.3)
  • From: Grzegorz Jaśkiewicz
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: some problems when i use postgresql 8.4.2 in my projects .
  • From: Pierre Frédéric Caillaud
• Re: Slow query: table iteration (8.3)
  • From: Glenn Maynard
• Re: foreign key constraint lock behavour in postgresql
  • From: david
• Re: System overload / context switching / oom, 8.3
  • From: Greg Smith
• foreign key constraint lock behavour in postgresql
  • From: wangyuxiang
• Re: Slow query: table iteration (8.3)
  • From: Robert Haas
• Re: System overload / context switching / oom, 8.3
  • From: Rob Lemley
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Greg Smith
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Robert Haas
• Re: System overload / context switching / oom, 8.3
  • From: Robert Haas
• Re: Queries within a function
  • From: Mridula Mahadevan
• Re: Slow-ish Query Needs Some Love
  • From: Andy Colson
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Andy Colson
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Ivan Voras
• Re: Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Reid Thompson
• Re: Queries within a function
  • From: Віталій Тимчишин
• Re: queries with subquery constraints on partitioned tables not optimized?
  • From: Nikolas Everett
• Re: some problems when i use postgresql 8.4.2 in my projects .
  • From: Leo Mannhart
• Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Optimizing Postgresql server and FreeBSD for heavy read and writes
  • From: Amitabh Kant
• Re: some problems when i use postgresql 8.4.2 in my projects .
  • From: Robert Haas
• Re: [HACKERS] 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: Robert Haas
• Re: [HACKERS] 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: Greg Stark
• Re: System overload / context switching / oom, 8.3
  • From: Matthew Wakeling
• Re: queries with subquery constraints on partitioned tables not optimized?
  • From: Dimitri Fontaine
• Re: the jokes for pg concurrency write performance
  • From: J Sisson
• Re: System overload / context switching / oom, 8.3
  • From: Greg Smith
• Re: the jokes for pg concurrency write performance
  • From: Greg Smith
• Re: Queries within a function
  • From: ramasubramanian
• some problems when i use postgresql 8.4.2 in my projects .
  • From: wyx6fox
• Re: queries with subquery constraints on partitioned tables not optimized?
  • From: Tom Lane
• Slow-ish Query Needs Some Love
  • From: Matt White
• queries with subquery constraints on partitioned tables not optimized?
  • From: Davor J.
• Re: Slow-ish Query Needs Some Love
  • From: Edgardo Portal
• Re: Slow-ish Query Needs Some Love
  • From: Matt White
• Re: System overload / context switching / oom, 8.3
  • From: Rob
• Re: System overload / context switching / oom, 8.3
  • From: Rob
• Re: Queries within a function
  • From: Mridula Mahadevan
• Re: System overload / context switching / oom, 8.3
  • From: Andy Colson
• Re: Queries within a function
  • From: Mridula Mahadevan
• Re: System overload / context switching / oom, 8.3
  • From: Andy Colson
• Re: System overload / context switching / oom, 8.3
  • From: Kevin Grittner
• Re: System overload / context switching / oom, 8.3
  • From: Scott Marlowe
• Re: Slow-ish Query Needs Some Love
  • From: Andy Colson
• Re: Re: 回复：Re: [PERFORM] the jokes for pg concurrency write performance
  • From: Tom Lane
• Re: Queries within a function
  • From: "Ing. Marcos Orti­z Valmaseda"
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Tom Lane
• Re: Queries within a function
  • From: Tom Lane
• System overload / context switching / oom, 8.3
  • From: Rob
• Re: Queries within a function
  • From: Pavel Stehule
• Re: [HACKERS] 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: Robert Haas
• 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: Greg Stark
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Andres Freund
• Queries within a function
  • From: Mridula Mahadevan
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: the jokes for pg concurrency write performance
  • From: Scott Marlowe
• Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
  • From: Robert Haas
• Re: [HACKERS] 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: Tom Lane
• Re: 回复：Re: [PERFORM] the jokes for pg concurrency write performance
  • From: Richard Broersma
• Re: the jokes for pg concurrency write performance
  • From: Alvaro Herrera
• Re: the jokes for pg concurrency write performance
  • From: Scott Marlowe
• Re: Slow query: table iteration (8.3)
  • From: Yeb Havinga
• Sincere apology for my insults and hand-waving in these mails:the jokes for pg concurrency write performance
  • From: wyx6fox
• Re: the jokes for pg concurrency write performance
  • From: Richard Broersma
• Re: the jokes for pg concurrency write performance
  • From: david
• 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