Postgres Performance Date Index

• Thread Index

• Re: SSD + RAID
  • From: Laszlo Nagy
• Re: SSD + RAID
  • From: Karl Denninger
• SSD + RAID
  • From: Laszlo Nagy
• Re: Manual vacs 5x faster than autovacs?
  • From: Dave Crooke
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Wayne Beaver
• activerecord-jdbc-adapter bug can affect RoR query performance
  • From: Kevin Grittner
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Wayne Beaver
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Tom Lane
• Manual vacs 5x faster than autovacs?
  • From: Wayne Beaver
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Why age (datfrozenxid) in postgres becomes 1073742202 not zero after each vacuum of database.
  • From: Brahma Prakash Tiwari
• Re: limiting performance impact of wal archiving.
  • From: Scott Carey
• Re: limiting performance impact of wal archiving.
  • From: Greg Smith
• Re: Adaptec Zero-Maintenance Cache Protection - Anyone using?
  • From: Robert Schnabel
• Adaptec Zero-Maintenance Cache Protection - Anyone using?
  • From: Glyn Astill
• Database tuning at Duke
  • From: Greg Smith
• Re: limiting performance impact of wal archiving.
  • From: Jeff
• Re: limiting performance impact of wal archiving.
  • From: Scott Marlowe
• Re: limiting performance impact of wal archiving.
  • From: Greg Smith
• Re: limiting performance impact of wal archiving.
  • From: Greg Smith
• Re: limiting performance impact of wal archiving.
  • From: Greg Smith
• Re: limiting performance impact of wal archiving.
  • From: Scott Marlowe
• Re: limiting performance impact of wal archiving.
  • From: Craig James
• Re: limiting performance impact of wal archiving.
  • From: Scott Marlowe
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: limiting performance impact of wal archiving.
  • From: Greg Smith
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: limiting performance impact of wal archiving.
  • From: Kevin Grittner
• Re: limiting performance impact of wal archiving.
  • From: Scott Marlowe
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: limiting performance impact of wal archiving.
  • From: Ivan Voras
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: limiting performance impact of wal archiving.
  • From: Ivan Voras
• Re: limiting performance impact of wal archiving.
  • From: Kenneth Marshall
• limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: CREATE TABLE slowing down significantly over time
  • From: Greg Smith
• Re: random_page_cost for tablespace
  • From: Laszlo Nagy
• Re: CREATE TABLE slowing down significantly over time
  • From: Robert Haas
• Re: CREATE TABLE slowing down significantly over time
  • From: Scott Marlowe
• Re: CREATE TABLE slowing down significantly over time
  • From: Anj Adu
• Re: maintaining a reference to a fetched row
  • From: Dimitri Fontaine
• Re: random_page_cost for tablespace
  • From: Robert Haas
• random_page_cost for tablespace
  • From: Laszlo Nagy
• Re: CREATE TABLE slowing down significantly over time
  • From: Robert Haas
• Re: CREATE TABLE slowing down significantly over time
  • From: Grzegorz Jaśkiewicz
• Re: CREATE TABLE slowing down significantly over time
  • From: Robert Haas
• Re: CREATE TABLE slowing down significantly over time
  • From: Scott Marlowe
• Re: CREATE TABLE slowing down significantly over time
  • From: Aris Samad-Yahaya
• Re: CREATE TABLE slowing down significantly over time
  • From: Aris Samad-Yahaya
• Re: CREATE TABLE slowing down significantly over time
  • From: Craig Ringer
• Re: CREATE TABLE slowing down significantly over time
  • From: Tom Lane
• CREATE TABLE slowing down significantly over time
  • From: Aris Samad-Yahaya
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Alvaro Herrera
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Kevin Grittner
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Craig James
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Greg Smith
• High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Jay Manni
• Problem with database performance, Debian 4gb ram ?
  • From: Massan
• Re: Followup: vacuum'ing toast
  • From: Craig Ringer
• Re: Running some query in low priority
  • From: Scott Marlowe
• Re: Followup: vacuum'ing toast
  • From: Greg Smith
• Re: Running some query in low priority
  • From: Grzegorz Jaśkiewicz
• Re: Running some query in low priority
  • From: Matthew Wakeling
• Re: Running some query in low priority
  • From: Grzegorz Jaśkiewicz
• Re: Running some query in low priority
  • From: S Arvind
• Re: Followup: vacuum'ing toast
  • From: Craig Ringer
• Re: Followup: vacuum'ing toast
  • From: Craig Ringer
• Re: Running some query in low priority
  • From: Greg Stark
• Re: Running some query in low priority
  • From: Grzegorz Jaśkiewicz
• Running some query in low priority
  • From: S Arvind
• Re: Followup: vacuum'ing toast
  • From: Eduardo Morras
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Jay Manni
• Re: Optimizer + bind variables
  • From: Scott Carey
• Re: maintaining a reference to a fetched row
  • From: Jeff Janes
• Re: Followup: vacuum'ing toast
  • From: Craig Ringer
• Re: Followup: vacuum'ing toast
  • From: Greg Smith
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Craig Ringer
• Followup: vacuum'ing toast
  • From: Dave Crooke
• Re: vacuum'ing toast crumbs, detecting dangling transactions
  • From: Scott Marlowe
• Re: vacuum'ing toast crumbs, detecting dangling transactions
  • From: Kevin Grittner
• vacuum'ing toast crumbs, detecting dangling transactions
  • From: Dave Crooke
• Re: maintaining a reference to a fetched row
  • From: Tom Lane
• Re: maintaining a reference to a fetched row
  • From: Brian Karlak
• Re: maintaining a reference to a fetched row
  • From: Brian Karlak
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Anj Adu
• Re: maintaining a reference to a fetched row
  • From: Jeff Janes
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Jeff Janes
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Greg Smith
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Merlin Moncure
• Re: Free memory usage Sol10, 8.2.9
  • From: Ivan Voras
• Re: maintaining a reference to a fetched row
  • From: Tom Lane
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: David Saracini
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Scott Marlowe
• High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Jay Manni
• Re: Optimizer + bind variables
  • From: David Kerr
• Re: maintaining a reference to a fetched row
  • From: Brian Karlak
• Re: maintaining a reference to a fetched row
  • From: Craig Ringer
• Re: Optimizer + bind variables
  • From: Chris
• Re: Optimizer + bind variables
  • From: David Kerr
• Re: Optimizer + bind variables
  • From: Craig Ringer
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Re: Free memory usage Sol10, 8.2.9
  • From: Jeremy Harris
• maintaining a reference to a fetched row
  • From: Brian Karlak
• Free memory usage Sol10, 8.2.9
  • From: Subbiah Stalin-XCGF84
• Re: Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Kevin Grittner
• Optimizer + bind variables
  • From: David Kerr
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Jeff Janes
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Re: Queryplan within FTS/GIN index -search.
  • From: Tom Lane
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Kevin Grittner
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Re: Queryplan within FTS/GIN index -search.
  • From: Tom Lane
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Re: database size growing continously
  • From: Robert Haas
• Re: database size growing continously
  • From: Anj Adu
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Ivan Voras
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Grzegorz Jaśkiewicz
• Problem with database performance, Debian 4gb ram ?
  • From: Grant Masan
• Re: database size growing continously
  • From: Peter Meszaros
• Re: Compression in PG
  • From: Eduardo Morras
• Re: Compression in PG
  • From: Robert Haas
• Re: Compression in PG
  • From: Scott Marlowe
• Re: Compression in PG
  • From: Adam Tauno Williams
• Re: Compression in PG
  • From: Shaul Dar
• Re: Compression in PG
  • From: Scott Marlowe
• Re: Compression in PG
  • From: Jesper Krogh
• Re: Compression in PG
  • From: Pavel Stehule
• Compression in PG
  • From: Shaul Dar
• Re: Modeling a table with arbitrary columns
  • From: Robert Haas
• Re: Queryplan within FTS/GIN index -search.
  • From: Greg Stark
• Re: Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: Queryplan within FTS/GIN index -search.
  • From: Tom Lane
• Re: database size growing continously
  • From: Greg Stark
• Re: database size growing continously
  • From: Jeremy Harris
• Re: database size growing continously
  • From: Anj Adu
• Re: database size growing continously
  • From: Greg Stark
• Re: database size growing continously
  • From: Anj Adu
• Re: Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: database size growing continously
  • From: Jeremy Harris
• Re: sub-select in IN clause results in sequential scan
  • From: Robert Haas
• Re: database size growing continously
  • From: Merlin Moncure
• Re: sub-select in IN clause results in sequential scan
  • From: Grzegorz Jaśkiewicz
• Re: Modeling a table with arbitrary columns
  • From: Віталій Тимчишин
• Re: AMD, Intel and RAID controllers
  • From: Greg Smith
• Re: optimizing query with multiple aggregates
  • From: Doug Cole
• Re: Modeling a table with arbitrary columns
  • From: Thomas Kellerer
• Modeling a table with arbitrary columns
  • From: Andreas Hartmann
• Re: database size growing continously
  • From: Scott Marlowe
• Re: query planning different in plpgsql?
  • From: Scott Carey
• Re: database size growing continously
  • From: Steve Crawford
• Re: database size growing continously
  • From: Steve Crawford
• Re: database size growing continously
  • From: Joshua D. Drake
• Re: database size growing continously
  • From: Chris Ernst
• Re: database size growing continously
  • From: Ludwik Dylag
• Re: database size growing continously
  • From: Matthew Wakeling
• Re: database size growing continously
  • From: Josh Rovero
• Re: sub-select in IN clause results in sequential scan
  • From: Anj Adu
• Re: sub-select in IN clause results in sequential scan
  • From: Robert Haas
• Re: database size growing continously
  • From: Ludwik Dylag
• Re: sub-select in IN clause results in sequential scan
  • From: Bob Lunney
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Tom Lane
• database size growing continously
  • From: Peter Meszaros
• Re: query planning different in plpgsql?
  • From: Michal J. Kubski
• Re: Postgresql optimisation
  • From: Denis BUCHER
• Re: query planning different in plpgsql?
  • From: Michal J. Kubski
• Re: sub-select in IN clause results in sequential scan
  • From: Anj Adu
• Re: sub-select in IN clause results in sequential scan
  • From: Angayarkanni
• Re: sub-select in IN clause results in sequential scan
  • From: Grzegorz Jaśkiewicz
• sub-select in IN clause results in sequential scan
  • From: Anj Adu
• Re: Postgresql optimisation
  • From: Dave Dutcher
• Re: Postgresql optimisation
  • From: Matthew Wakeling
• Re: Postgresql optimisation
  • From: Dave Dutcher
• Re: Postgresql optimisation
  • From: Greg Smith
• Re: Postgresql optimisation
  • From: Denis BUCHER
• Re: Postgresql optimisation
  • From: Kevin Grittner
• Re: Postgresql optimisation
  • From: Grzegorz Jaśkiewicz
• Re: Postgresql optimisation
  • From: Denis BUCHER
• Re: Postgresql optimisation
  • From: Grzegorz Jaśkiewicz
• Postgresql optimisation
  • From: Denis BUCHER
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Robert Haas
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: jesper
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Robert Haas
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Craig Ringer
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Jesper Krogh
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Jesper Krogh
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Craig Ringer
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Jesper Krogh
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Craig Ringer
• bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Jesper Krogh
• Re: query planning different in plpgsql?
  • From: Waldomiro
• Re: query planning different in plpgsql?
  • From: Tom Lane
• Re: Full text search - query plan? PG 8.4.1
  • From: Tom Lane
• Re: Full text search - query plan? PG 8.4.1
  • From: Jesper Krogh
• Re: query planning different in plpgsql?
  • From: Michal J. Kubski
• Re: query planning different in plpgsql?
  • From: Merlin Moncure
• Re: query planning different in plpgsql?
  • From: Michal J. Kubski
• Re: optimizing query with multiple aggregates
  • From: Marc Mamin
• Re: Domain vs table
  • From: decibel
• Re: Table Clustering & Time Range Queries
  • From: Greg Smith
• Re: Full text search - query plan? PG 8.4.1
  • From: Jesper Krogh
• Re: Table Clustering & Time Range Queries
  • From: Stephen Frost
• Re: Full text search - query plan? PG 8.4.1
  • From: Scott Marlowe
• Re: Full text search - query plan? PG 8.4.1
  • From: Tom Lane
• Re: Full text search - query plan? PG 8.4.1
  • From: Jesper Krogh
• Re: Calculating selectivity for the query-planner on ts_vector colums.
  • From: Jesper Krogh
• Re: Queryplan within FTS/GIN index -search.
  • From: Jeff Davis
• Re: Table Clustering & Time Range Queries
  • From: Kevin Buckham
• Re: Calculating selectivity for the query-planner on ts_vector colums.
  • From: Tom Lane
• Calculating selectivity for the query-planner on ts_vector colums.
  • From: Jesper Krogh
• Re: Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: Queryplan within FTS/GIN index -search.
  • From: Richard Huxton
• Re: query planning different in plpgsql?
  • From: Tom Lane
• Re: Queryplan within FTS/GIN index -search.
  • From: Jeff Davis
• Re: query planning different in plpgsql?
  • From: Grzegorz Jaśkiewicz
• Re: Queryplan within FTS/GIN index -search.
  • From: Jeff Davis
• Re: query planning different in plpgsql?
  • From: Scott Mead
• query planning different in plpgsql?
  • From: Michal J. Kubski
• Re: Queryplan within FTS/GIN index -search.
  • From: Richard Huxton
• Re: Queryplan within FTS/GIN index -search.
  • From: jesper
• Re: Queryplan within FTS/GIN index -search.
  • From: Richard Huxton
• Re: Queryplan within FTS/GIN index -search.
  • From: jesper
• Re: Table Clustering & Time Range Queries
  • From: Scara Maccai
• Re: Queryplan within FTS/GIN index -search.
  • From: Jeff Davis
• Re: Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: Queryplan within FTS/GIN index -search.
  • From: Jeff Davis
• Re: Partitioned Tables and ORDER BY
  • From: Scott Carey
• Re: optimizing query with multiple aggregates
  • From: Scott Carey
• Re: Table Clustering & Time Range Queries
  • From: Scott Carey
• Re: Table Clustering & Time Range Queries
  • From: Kevin Grittner
• Table Clustering & Time Range Queries
  • From: Kevin Buckham
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: optimizing query with multiple aggregates
  • From: Robert Haas
• Re: optimizing query with multiple aggregates
  • From: Kenneth Marshall
• Re: There is a statistic table?
  • From: Cédric Villemain
• Re: maintain_cluster_order_v5.patch
  • From: Heikki Linnakangas
• Re: Random penalties on GIN index updates?
  • From: Jesper Krogh
• Re: Random penalties on GIN index updates?
  • From: Robert Haas
• Re: optimizing query with multiple aggregates
  • From: Nikolas Everett
• Re: optimizing query with multiple aggregates
  • From: David Wilson
• Re: optimizing query with multiple aggregates
  • From: Doug Cole
• Re: optimizing query with multiple aggregates
  • From: Merlin Moncure
• optimizing query with multiple aggregates
  • From: Doug Cole
• Re: There is a statistic table?
  • From: Scott Marlowe
• Re: Are unreferenced TOASTed values retrieved?
  • From: Tom Lane
• Re: Random penalties on GIN index updates?
  • From: Tom Lane
• Are unreferenced TOASTed values retrieved?
  • From: William Blunn
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Scott Carey
• Re: Random penalties on GIN index updates?
  • From: Jesper Krogh
• Re: maintain_cluster_order_v5.patch
  • From: phb07@xxxxxxxxxxxx
• Re: There is a statistic table?
  • From: Scott Carey
• Re: Random penalties on GIN index updates?
  • From: Tom Lane
• Random penalties on GIN index updates?
  • From: jesper
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Shaul Dar
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Melton Low
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Tom Lane
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: A. Kretschmer
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Shaul Dar
• Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Shaul Dar
• Re: Domain vs table
  • From: Merlin Moncure
• Re: Performance with sorting and LIMIT on partitioned table
  • From: Joe Uhl
• Re: Performance with sorting and LIMIT on partitioned table
  • From: Merlin Moncure
• Re: maintain_cluster_order_v5.patch
  • From: Jeff Davis
• maintain_cluster_order_v5.patch
  • From: phb07@xxxxxxxxxxxx
• Re: Partitioned Tables and ORDER BY
  • From: Robert Haas
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Simon Riggs
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Gerhard Wiesinger
• Re: Calculation of unused columns
  • From: Simon Riggs
• Re: Calculation of unused columns
  • From: Kevin Grittner
• Re: Partitioned Tables and ORDER BY
  • From: Craig James
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Simon Riggs
• Re: Partitioned Tables and ORDER BY
  • From: Grzegorz Jaśkiewicz
• Re: Partitioned Tables and ORDER BY
  • From: Robert Haas
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Indexes on low cardinality columns
  • From: Ron Mayer
• Re: Known Bottlenecks
  • From: Grzegorz Jaśkiewicz
• Known Bottlenecks
  • From: Vikul Khosla
• Re: Performance with sorting and LIMIT on partitioned table
  • From: Joe Uhl
• Re: Issues with \copy from file
  • From: Matthew Wakeling
• Re: Partitioned Tables and ORDER BY
  • From: Grzegorz Jaśkiewicz
• Re: Performance with sorting and LIMIT on partitioned table
  • From: Robert Haas
• Re: Improving join performance over multiple moderately wide tables
  • From: Robert Haas
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Robert Haas
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Robert Haas
• Re: Full text search - query plan? PG 8.4.1
  • From: Tom Lane
• Re: Full text search - query plan? PG 8.4.1
  • From: Jesper Krogh
• Re: Full text search - query plan? PG 8.4.1
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Jeff Janes
• Re: Calculation of unused columns
  • From: Tim Landscheidt
• Full text search - query plan? PG 8.4.1
  • From: Jesper Krogh
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: sequential scan on child partition tables
  • From: Anj Adu
• Re: Calculation of unused columns
  • From: Daniel Migowski
• Re: Partitioned Tables and ORDER BY
  • From: Joe Uhl
• Re: Issues with \copy from file
  • From: Scott Marlowe
• Re: Issues with \copy from file
  • From: Euler Taveira de Oliveira
• Re: sequential scan on child partition tables
  • From: Scott Marlowe
• Re: table full scan or index full scan?
  • From: Melton Low
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Scott Marlowe
• Re: table full scan or index full scan?
  • From: Euler Taveira de Oliveira
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Karl Denninger
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Tory M Blue
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Karl Denninger
• Re: Calculation of unused columns
  • From: Tom Lane
• Improving join performance over multiple moderately wide tables
  • From: miller_2555
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Torsten Zühlsdorff
• sequential scan on child partition tables
  • From: Anj Adu
• Re: Indexes on low cardinality columns
  • From: Vikul Khosla
• Issues with \copy from file
  • From: Sigurgeir Gunnarsson
• Performance with sorting and LIMIT on partitioned table
  • From: Michal Szymanski
• Re: Partitioned Tables and ORDER BY
  • From: Michal Szymanski
• Re: Domain vs table
  • From: Michal Szymanski
• Domain vs table
  • From: Michal Szymanski
• table full scan or index full scan?
  • From: 旭斌 裴
• Re: Partitioned Tables and ORDER BY
  • From: Michal Szymanski
• Re: Calculation of unused columns
  • From: Robert Haas
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Tom Lane
• Calculation of unused columns
  • From: Volker Grabsch
• Re: Indexes on low cardinality columns
  • From: Jeff Janes
• Re: Indexes on low cardinality columns
  • From: Robert Haas
• Re: Indexes on low cardinality columns
  • From: Vikul Khosla
• Re: UUID as primary key
  • From: decibel
• Re: Indexes on low cardinality columns
  • From: Greg Stark
• Indexes on low cardinality columns
  • From: Vikul Khosla
• Re: UUID as primary key
  • From: Alvaro Herrera
• Re: UUID as primary key
  • From: decibel
• Re: There is a statistic table?
  • From: Albe Laurenz
• Re: There is a statistic table?
  • From: Scott Marlowe
• There is a statistic table?
  • From: waldomiro
• Re: sequential scan on child partition tables
  • From: Anj Adu
• Regarding facing lot of time Consumed by Socket.Poll()
  • From: keshav upadhyaya
• [OT] Recommended whitebox server vendors in the UK?
  • From: Glyn Astill
• Re: sequential scan on child partition tables
  • From: Tom Lane
• sequential scan on child partition tables
  • From: Anj Adu
• Re: Getting a random row
  • From: Віталій Тимчишин
• Re: Getting a random row
  • From: Scott Marlowe
• Re: Getting a random row
  • From: Pavel Stehule
• Re: Getting a random row
  • From: Thom Brown
• Re: Getting a random row
  • From: Scott Marlowe
• Re: Getting a random row
  • From: bricklen
• Re: Getting a random row
  • From: Robert Haas
• Re: Getting a random row
  • From: Shaul Dar
• Re: Getting a random row
  • From: Grzegorz Jaśkiewicz
• Re: Getting a random row
  • From: Michael Glaesemann
• Re: Getting a random row
  • From: Shaul Dar
• Re: Getting a random row
  • From: Thomas Kellerer
• Re: Getting a random row
  • From: Grzegorz Jaśkiewicz
• Getting a random row
  • From: Shaul Dar
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Kenneth Marshall
• Re: index on two tables or Howto speedup max/aggregate-function
  • From: Grzegorz Jaśkiewicz
• Re: index on two tables or Howto speedup max/aggregate-function
  • From: Jacques Caron
• index on two tables or Howto speedup max/aggregate-function
  • From: Michael Schwipps
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Scott Marlowe
• Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Tory M Blue
• Re: Best suiting OS
  • From: Dimitri Fontaine
• Re: Query performance
  • From: Grzegorz Jaśkiewicz
• Re: Query performance
  • From: S Arvind
• Re: Query performance
  • From: S Arvind
• Re: updating a row in a table with only one row
  • From: Merlin Moncure
• Re: Best suiting OS
  • From: Cédric Villemain
• Re: Query performance
  • From: Grzegorz Jaśkiewicz
• Re: Query performance
  • From: Matthew Wakeling
• Re: Query performance
  • From: Grzegorz Jaśkiewicz
• Re: Query performance
  • From: S Arvind
• Re: Query performance
  • From: Matthew Wakeling
• Re: Query performance
  • From: S Arvind
• Re: Query performance
  • From: Grzegorz Jaśkiewicz
• Query performance
  • From: S Arvind
• Re: updating a row in a table with only one row
  • From: Michal Vitecek
• Re: Using unnest function on multi-dimensional array.
  • From: Pavel Stehule
• Using unnest function on multi-dimensional array.
  • From: Nimesh Satam
• Re: table partitioning & max_locks_per_transaction
  • From: Brian Karlak
• Re: vacuumdb command
  • From: Heikki Linnakangas
• vacuumdb command
  • From: soorjith p
• Re: table partitioning & max_locks_per_transaction
  • From: Tom Lane
• Re: Databases vs Schemas
  • From: Scott Marlowe
• table partitioning & max_locks_per_transaction
  • From: Brian Karlak
• Re: UUID as primary key
  • From: Mark Mielke
• Re: Databases vs Schemas
  • From: Chris Kratz
• Re: Databases vs Schemas
  • From: Merlin Moncure
• Re: UUID as primary key
  • From: tsuraan
• Re: Databases vs Schemas
  • From: Tom Lane
• Re: Databases vs Schemas
  • From: Scott Carey
• Re: disk I/O problems and Solutions
  • From: Scott Carey
• Re: disk I/O problems and Solutions
  • From: David Rees
• Re: Databases vs Schemas
  • From: Merlin Moncure
• Re: disk I/O problems and Solutions
  • From: Scott Marlowe
• Re: disk I/O problems and Solutions
  • From: Flavio Henrique Araque Gurgel
• Re: UUID as primary key
  • From: Mark Mielke
• Re: Databases vs Schemas
  • From: Ben Chobot
• Databases vs Schemas
  • From: Scott Otis
• Re: concurrent reindex issues
  • From: Tory M Blue
• UUID as primary key
  • From: tsuraan
• disk I/O problems and Solutions
  • From: Alan McKay
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Merlin Moncure
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Kenneth Marshall
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Xia Qingran
• Re: Explain Analyze returns faster than psql or JDBC calls.
  • From: Dave Cramer
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: Explain Analyze returns faster than psql or JDBC calls.
  • From: Tom Lane
• Re: dump time increase by 1h with new kernel
  • From: Justin T Pryzby
• Re: dump time increase by 1h with new kernel
  • From: Kevin Grittner
• Explain Analyze returns faster than psql or JDBC calls.
  • From: G B
• Re: dump time increase by 1h with new kernel
  • From: Justin T Pryzby
• Re: concurrent reindex issues
  • From: Scott Marlowe
• Re: concurrent reindex issues
  • From: Tom Lane
• Re: dump time increase by 1h with new kernel
  • From: Joshua D. Drake
• Re: dump time increase by 1h with new kernel
  • From: Justin T Pryzby
• concurrent reindex issues
  • From: Tory M Blue
• Partitioned Tables and ORDER BY
  • From: Joe Uhl
• Re: position in DDL of columns used in indexes
  • From: Tom Lane
• Re: position in DDL of columns used in indexes
  • From: Matthew Wakeling
• position in DDL of columns used in indexes
  • From: Michael Gould
• Re: Best suiting OS
  • From: Matthew Wakeling
• Query logging time, not values
  • From: Ludwik Dylag
• Regarding mulitple rows insert in one shot using ADO .net connected to postgres
  • From: keshav upadhyaya
• Re: dump time increase by 1h with new kernel
  • From: Greg Smith
• Re: Query plan for NOT IN
  • From: Guy Rouillier
• Re: Query plan for NOT IN
  • From: Craig James
• Re: Query plan for NOT IN
  • From: Kevin Grittner
• Re: Query plan for NOT IN
  • From: Guy Rouillier
• Re: Query plan for NOT IN
  • From: Kevin Grittner
• Re: Query plan for NOT IN
  • From: Grzegorz Jaśkiewicz
• Re: Speed / Server
  • From: richard.henwood
• Re: Speed / Server
  • From: Greg Smith
• Re: Speed / Server
  • From: Anthony Presley
• Re: Speed / Server
  • From: Merlin Moncure
• Re: Speed / Server
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: Scott Mead
• Re: Speed / Server
  • From: Karl Denninger
• Re: Speed / Server
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: david
• Re: updating a row in a table with only one row
  • From: Craig James
• Re: updating a row in a table with only one row
  • From: Merlin Moncure
• Re: updating a row in a table with only one row
  • From: Michal Vitecek
• Re: Speed / Server
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Dumping + restoring a subset of a table?
  • From: Joshua Tolley
• Re: Speed / Server
  • From: Nikolas Everett
• Dumping + restoring a subset of a table?
  • From: Shaul Dar
• Re: What is the role of #fsync and #synchronous_commit in configuration file .
  • From: Dave Dutcher
• Re: Best suiting OS
  • From: Axel Rau
• What is the role of #fsync and #synchronous_commit in configuration file .
  • From: keshav upadhyaya
• Re: Distributed/Parallel Computing
  • From: Viji V Nair
• Re: Distributed/Parallel Computing
  • From: Jeff Janes
• Re: Maybe OT, not sure Re: Best suiting OS
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Speed / Server
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: Claus Guttesen
• Re: Best suiting OS
  • From: Axel Rau
• Re: Best suiting OS
  • From: Kevin Grittner
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Query plan for NOT IN
  • From: Guy Rouillier
• Distributed/Parallel Computing
  • From: Viji V Nair
• Re: Speed while runnning large transactions.
  • From: Greg Smith
• Re: Best suiting OS
  • From: Scott Carey
• Re: Best suiting OS
  • From: Greg Smith
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Best suiting OS
  • From: Axel Rau
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Best suiting OS
  • From: Scott Carey
• Re: Best suiting OS
  • From: Claus Guttesen
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Best suiting OS
  • From: Scott Carey
• Re: Performance RAID 0
  • From: Fernando Hevia
• Re: Best suiting OS
  • From: Stefan Kaltenbrunner
• Re: Best suiting OS
  • From: Stefan Kaltenbrunner
• Re: Query plan for NOT IN
  • From: Tom Lane
• Re: Query plan for NOT IN
  • From: Grzegorz Jaśkiewicz
• Re: Query plan for NOT IN
  • From: Matthew Wakeling
• Re: Query plan for NOT IN
  • From: Grzegorz Jaśkiewicz
• Query plan for NOT IN
  • From: Matthew Wakeling
• Re: [OT] Best suiting OS
  • From: Csaba Nagy
• Re: Best suiting OS
  • From: Adam Tauno Williams
• Re: Best suiting OS
  • From: Jean-David Beyer
• Re: Speed / Server
  • From: Nikolas Everett
• Re: Best suiting OS
  • From: Robert Haas
• Re: Maybe OT, not sure Re: Best suiting OS
  • From: Adam Tauno Williams
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Grzegorz Jaśkiewicz
• Re: Best suiting OS
  • From: Adam Tauno Williams
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Omar Kilani
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Robert Haas
• Re: updating a row in a table with only one row
  • From: Merlin Moncure
• Re: Best suiting OS
  • From: Devrim GÜNDÜZ
• Re: Best suiting OS
  • From: Devrim GÜNDÜZ
• Re: Best suiting OS
  • From: Jean-Michel Pouré
• Re: Best suiting OS
  • From: Devrim GÜNDÜZ
• Re: updating a row in a table with only one row
  • From: Michal Vitecek
• Re: Best suiting OS
  • From: Craig James
• Maybe OT, not sure Re: Best suiting OS
  • From: Mark Mielke
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Omar Kilani
• Re: Best suiting OS
  • From: Scott Marlowe
• Re: Speed / Server
  • From: Scott Marlowe
• Speed / Server
  • From: anthony
• Re: Best suiting OS
  • From: david
• Re: Best suiting OS
  • From: Gerhard Wiesinger
• Re: Best suiting OS
  • From: Mark Mielke
• Re: Confusion on shared buffer
  • From: Robert Haas
• Re: Best suiting OS
  • From: Devrim GÜNDÜZ
• Re: Best suiting OS
  • From: Mark Mielke
• Re: Confusion on shared buffer
  • From: Gurjeet Singh
• Re: Postgres performance
  • From: Gerd Koenig
• Re: dump time increase by 1h with new kernel
  • From: Scott Marlowe
• Re: Performance problems with DISTINCT ON
  • From: Tom Lane
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Performance problems with DISTINCT ON
  • From: imad
• dump time increase by 1h with new kernel
  • From: Justin Pryzby
• Re: Best suiting OS
  • From: Jon Nelson
• Re: AMD, Intel and RAID controllers
  • From: Alpesh Gajbe
• Re: Best suiting OS
  • From: Denis Lussier
• Performance RAID 0
  • From: mange
• Re: PG 8.3 and large shared buffer settings
  • From: Hannu Krosing
• Performance problems with DISTINCT ON
  • From: Sgarbossa Domenico
• Re: Use of sequence rather than index scan for one text column on one instance of a database
  • From: Bill Kirtley
• Postgres performance
  • From: std pik
• Re: Confusion on shared buffer
  • From: Robert Haas
• Re: Confusion on shared buffer
  • From: S Arvind
• Re: dump time increase by 1h with new kernel
  • From: Tom Lane
• dump time increase by 1h with new kernel
  • From: Justin Pryzby
• Re: Speed while runnning large transactions.
  • From: Tom Lane
• Re: Best suiting OS
  • From: Dimitri Fontaine
• Re: Best suiting OS
  • From: Tom Lane
• Re: Speed while runnning large transactions.
  • From: Kevin Grittner
• Re: Confusion on shared buffer
  • From: Robert Haas
• Re: Best suiting OS
  • From: Mark Mielke
• Re: Best suiting OS
  • From: Kevin Grittner
• Re: updating a row in a table with only one row
  • From: Heikki Linnakangas
• Re: updating a row in a table with only one row
  • From: Merlin Moncure
• Re: Best suiting OS
  • From: Greg Smith
• Re: updating a row in a table with only one row
  • From: Robert Haas
• Re: Best suiting OS
  • From: Greg Smith
• Re: Best suiting OS
  • From: Merlin Moncure
• Re: Best suiting OS
  • From: Greg Smith
• Re: Best suiting OS
  • From: Jon Nelson
• Re: Best suiting OS - now off topic
  • From: Aidan Van Dyk
• Re: Best suiting OS
  • From: Mark Mielke
• Re: Best suiting OS
  • From: Joe Uhl
• Re: Best suiting OS
  • From: Matthew Wakeling
• Re: Best suiting OS
  • From: Tom Lane
• Re: updating a row in a table with only one row
  • From: Merlin Moncure
• Re: AMD, Intel and RAID controllers
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: Devrim GÜNDÜZ
• Re: Best suiting OS
  • From: Matthew Wakeling
• Re: updating a row in a table with only one row
  • From: Hélder M. Vieira
• Re: Best suiting OS
  • From: Scara Maccai
• Re: updating a row in a table with only one row
  • From: A. Kretschmer
• updating a row in a table with only one row
  • From: Michal Vitecek
• Re: Best suiting OS
  • From: Scara Maccai
• Re: AMD, Intel and RAID controllers
  • From: alpesh gajbe
• Re: long running insert statement
  • From: Gerd König
• Re: Best suiting OS
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: david
• Re: AMD, Intel and RAID controllers
  • From: Greg Smith
• Re: Best suiting OS
  • From: Greg Smith
• Re: Best suiting OS
  • From: Greg Smith
• Re: Best suiting OS
  • From: S Arvind
• AMD, Intel and RAID controllers
  • From: Benjamin Minshall
• Re: Best suiting OS
  • From: Tom Lane
• Re: Speed while runnning large transactions.
  • From: Tom Lane
• Re: Best suiting OS
  • From: Haszlakiewicz, Eric
• Re: long running insert statement
  • From: Tom Lane
• Re: Database performance post-VACUUM FULL
  • From: Kevin Grittner
• Re: Best suiting OS
  • From: Claus Guttesen
• Re: Best suiting OS
  • From: S Arvind
• Re: long running insert statement
  • From: Matthew Wakeling
• Re: Best suiting OS
  • From: Jean-David Beyer
• Re: Best suiting OS
  • From: S Arvind
• Re: Speed while runnning large transactions.
  • From: Greg Smith
• Re: Best suiting OS
  • From: Jean-David Beyer
• Re: Best suiting OS
  • From: Matthew Wakeling
• Re: CPU cost of operators
  • From: Matthew Wakeling
• Best suiting OS
  • From: S Arvind
• Confusion on shared buffer
  • From: S Arvind
• long running insert statement
  • From: Gerd König
• Re: CPU cost of operators
  • From: Tom Lane
• Re: CPU cost of operators
  • From: Robert Haas
• Re: CPU cost of operators
  • From: Robert Haas
• CPU cost of operators
  • From: Matthew Wakeling
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Ivan Voras
• Re: FullTextSearch - UNION individual indexes or concatenated columns index ?
  • From: Josh Berkus
• Re: Speed while runnning large transactions.
  • From: Robert Haas
• FullTextSearch - UNION individual indexes or concatenated columns index ?
  • From: Jeremy Ferrante
• Re: Performance problems with DISTINCT ON
  • From: Scott Carey
• Re: Using OProfile
  • From: Tom Lane
• Re: Performance problems with DISTINCT ON
  • From: hubert depesz lubaczewski
• Re: Performance problems with DISTINCT ON
  • From: Sgarbossa Domenico
• Using OProfile
  • From: Reydan Cankur
• Re: Performance problems with DISTINCT ON
  • From: Richard Huxton
• Performance problems with DISTINCT ON
  • From: Sgarbossa Domenico
• Re: Postgres performance
  • From: Scott Marlowe
• Re: PG 8.3 and large shared buffer settings
  • From: Josh Berkus
• Re: Postgres performance
  • From: Andy Colson
• Re: LIMIT confuses the planner (again)
  • From: Robert Haas
• LIMIT confuses the planner (again)
  • From: Kouber Saparev
• Re: Regarding Sequential Scans count increase each time we press refresh .
  • From: Tom Lane
• Re: Slow query after upgrade to 8.4
  • From: Robert Haas
• Re: query memory consumption
  • From: Robert Haas
• Re: Regarding Sequential Scans count increase each time we press refresh .
  • From: Robert Haas
• Re: PG 8.3 and large shared buffer settings
  • From: Greg Smith
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Xia Qingran
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Xia Qingran
• Re: Many left outer joins with limit performance
  • From: Gerhard Wiesinger
• Re: query memory consumption
  • From: Jeff Janes
• Re: PG 8.3 and large shared buffer settings
  • From: Jeff Janes
• Re: PG 8.3 and large shared buffer settings
  • From: Aidan Van Dyk
• Re: PG 8.3 and large shared buffer settings
  • From: Scott Carey
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Craig James
• Re: PG 8.3 and large shared buffer settings
  • From: Aidan Van Dyk
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Gerhard Wiesinger
• Re: PG 8.3 and large shared buffer settings
  • From: Dan Sugalski
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Grzegorz Jaśkiewicz
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Grzegorz Jaśkiewicz
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: PG 8.3 and large shared buffer settings
  • From: Tom Lane
• PG 8.3 and large shared buffer settings
  • From: Dan Sugalski
• Re: Regarding Sequential Scans count increase each time we press refresh .
  • From: Josh Berkus
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Craig James
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Karl Denninger
• Regarding Sequential Scans count increase each time we press refresh .
  • From: keshav upadhyaya
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Dave Dutcher
• Re: Use of sequence rather than index scan for one text column on one instance of a database
  • From: Tom Lane
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Karl Denninger
• Re: Use of sequence rather than index scan for one text column on one instance of a database
  • From: Tom Lane
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Andy Colson
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Praveen DS
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: Slow query after upgrade to 8.4
  • From: Jared Beck
• Re: Speed while runnning large transactions.
  • From: jesper
• Re: Speed while runnning large transactions.
  • From: jesper
• Re: Slow query after upgrade to 8.4
  • From: tv
• Re: Index row requires 9324 bytes maximum size is 8191
  • From: solAris23
• Re: Speed while runnning large transactions.
  • From: Scott Marlowe
• Re: Speed while runnning large transactions.
  • From: Grzegorz Jaśkiewicz
• Re: Speed while runnning large transactions.
  • From: Claus Guttesen
• Speed while runnning large transactions.
  • From: jesper
• Re: Different query plans for the same query
  • From: Hell, Robert
• Re: Use of sequence rather than index scan for one text column on one instance of a database
  • From: Tom Lane
• Re: Slow query after upgrade to 8.4
  • From: Tom Lane
• Use of sequence rather than index scan for one text column on one instance of a database
  • From: Bill Kirtley
• Slow query after upgrade to 8.4
  • From: Jared Beck
• Re: Slow query after upgrade to 8.4
  • From: Greg Williamson
• Slow query after upgrade to 8.4
  • From: Jared Beck
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Scott Marlowe
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Karl Denninger
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Fernando Hevia
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Andy Colson
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: statement stats extra load?
  • From: Magnus Hagander