Postgres Performance Date Index

• Thread Index

• Re: slow DELETE on 12 M row table
  • From: Janet Jacobsen
• regression ? 8.4 do not apply One-Time Filter to subquery
  • From: Sergey Burladyan
• Re: - Slow Query
  • From: Tom Lane
• Re: - Slow Query
  • From: Scott Marlowe
• Re: - Slow Query
  • From: Mike Ivanov
• Re: - Slow Query
  • From: Tom Lane
• Re: - Slow Query
  • From: Scott Marlowe
• Re: - Slow Query
  • From: Rui Carvalho
• Re: - Slow Query
  • From: Mike Ivanov
• Re: - Slow Query
  • From: justin
• Re: - Slow Query
  • From: Mike Ivanov
• - Slow Query
  • From: Rui Carvalho
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Scott Carey
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Scott Carey
• Re: random slow query
  • From: Scott Carey
• Re: random slow query
  • From: Scott Carey
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Jean-David Beyer
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Alan Hodgson
• Re: random slow query
  • From: Scott Marlowe
• Re: random slow query
  • From: Scott Marlowe
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Scott Marlowe
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Scott Marlowe
• Re: random slow query
  • From: Sean Ma
• Re: random slow query
  • From: Scott Marlowe
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Sean Ma
• Re: Utilizing multiple cores in a function call.
  • From: Hartman, Matthew
• Re: Utilizing multiple cores in a function call.
  • From: Merlin Moncure
• Re: Utilizing multiple cores in a function call.
  • From: Hartman, Matthew
• Re: Insert performance and multi-column index order
  • From: Bob Lunney
• Re: Terrible Write Performance of a Stored Procedure
  • From: valgog
• Re: Utilizing multiple cores in a function call.
  • From: Craig Ringer
• Re: random slow query
  • From: Mike Ivanov
• Re: Utilizing multiple cores in a function call.
  • From: Merlin Moncure
• Re: Utilizing multiple cores in a function call.
  • From: Greg Smith
• Re: Utilizing multiple cores in a function call.
  • From: Joe Conway
• Re: Utilizing multiple cores in a function call.
  • From: Hartman, Matthew
• Re: random slow query
  • From: Kevin Grittner
• Re: Utilizing multiple cores in a function call.
  • From: Jean-David Beyer
• Utilizing multiple cores in a function call.
  • From: Hartman, Matthew
• Re: random slow query
  • From: Andres Freund
• random slow query
  • From: Sean Ma
• Re: Terrible Write Performance of a Stored Procedure
  • From: Scott Mead
• Re: what server stats to track / monitor ?
  • From: Alan McKay
• Re: slow DELETE on 12 M row table
  • From: Robert Haas
• Re: slow DELETE on 12 M row table
  • From: Scott Carey
• Re: Insert performance and multi-column index order
  • From: Greg Smith
• Re: what server stats to track / monitor ?
  • From: Greg Smith
• Re: slow DELETE on 12 M row table
  • From: Robert Haas
• Re: slow DELETE on 12 M row table
  • From: Janet Jacobsen
• Re: Insert performance and multi-column index order
  • From: Tom Lane
• Re: Terrible Write Performance of a Stored Procedure
  • From: Greg Smith
• Re: Nested Loop "Killer" on 8.1
  • From: Tom Lane
• Re: Terrible Write Performance of a Stored Procedure
  • From: Scott Mead
• Re: Terrible Write Performance of a Stored Procedure
  • From: Brian Troutwine
• Re: Terrible Write Performance of a Stored Procedure
  • From: Brian Troutwine
• Re: Terrible Write Performance of a Stored Procedure
  • From: Merlin Moncure
• Re: Terrible Write Performance of a Stored Procedure
  • From: Alan Hodgson
• Terrible Write Performance of a Stored Procedure
  • From: Brian Troutwine
• Re: Nested Loop "Killer" on 8.1
  • From: Dave North
• Insert performance and multi-column index order
  • From: bob_lunney
• Re: GiST index performance
  • From: Robert Haas
• Re: GiST index performance
  • From: Greg Smith
• Re: slow DELETE on 12 M row table
  • From: Marcin Stępnicki
• Re: slow DELETE on 12 M row table
  • From: Janet Jacobsen
• Re: slow DELETE on 12 M row table
  • From: Richard Huxton
• Re: slow DELETE on 12 M row table
  • From: Greg Stark
• slow DELETE on 12 M row table
  • From: Janet Jacobsen
• Re: Nested Loop "Killer" on 8.1
  • From: Greg Stark
• Re: Nested Loop "Killer" on 8.1
  • From: Tom Lane
• Re: Nested Loop "Killer" on 8.1
  • From: Mark Mielke
• Re: Nested Loop "Killer" on 8.1
  • From: Greg Stark
• Re: Nested Loop "Killer" on 8.1
  • From: Josh Berkus
• Re: Implications of having large number of users
  • From: Mike Ivanov
• Re: tsvector_update_trigger performance?
  • From: Dimitri Fontaine
• Re: tsvector_update_trigger performance?
  • From: Craig Ringer
• Re: tsvector_update_trigger performance?
  • From: Chris St Denis
• Re: tsvector_update_trigger performance?
  • From: Dimitri Fontaine
• Re: cluster index on a table
  • From: Scott Marlowe
• Re: cluster index on a table
  • From: Kenneth Marshall
• cluster index on a table
  • From: Ibrahim Harrani
• Re: tsvector_update_trigger performance?
  • From: Alvaro Herrera
• Re: Implications of having large number of users
  • From: Robert Haas
• Re: Implications of having large number of users
  • From: Tom Lane
• Re: Implications of having large number of users
  • From: Albe Laurenz
• Nested Loop "Killer" on 8.1
  • From: Dave North
• Re: Implications of having large number of users
  • From: Robert Haas
• Re: Implications of having large number of users
  • From: Albe Laurenz
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: tsvector_update_trigger performance?
  • From: Oleg Bartunov
• tsvector_update_trigger performance?
  • From: Chris St Denis
• Re: How would you store read/unread topic status?
  • From: Chris St Denis
• Re: How would you store read/unread topic status?
  • From: Greg Stark
• SOLVED: processor running queue - general rule of thumb?
  • From: Alan McKay
• Re: How would you store read/unread topic status?
  • From: Craig James
• Re: processor running queue - general rule of thumb?
  • From: Alan McKay
• Re: How would you store read/unread topic status?
  • From: Alexander Staubo
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Implications of having large number of users
  • From: Mike Ivanov
• Re: How would you store read/unread topic status?
  • From: Greg Stark
• Re: How would you store read/unread topic status?
  • From: Scott Carey
• Re: How would you store read/unread topic status?
  • From: Scott Carey
• Re: How would you store read/unread topic status?
  • From: Mike
• Re: How would you store read/unread topic status?
  • From: Mike
• Re: How would you store read/unread topic status?
  • From: Robert Haas
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: How would you store read/unread topic status?
  • From: Grzegorz Jaśkiewicz
• Re: How would you store read/unread topic status?
  • From: Robert Haas
• Re: How would you store read/unread topic status?
  • From: Andres Freund
• Re: How would you store read/unread topic status?
  • From: Guillaume Cottenceau
• Re: How would you store read/unread topic status?
  • From: Robert Haas
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: How would you store read/unread topic status?
  • From: Matthew Wakeling
• Re: How would you store read/unread topic status?
  • From: Nikolas Everett
• Re: How would you store read/unread topic status?
  • From: justin
• Re: How would you store read/unread topic status?
  • From: Andres Freund
• Re: How would you store read/unread topic status?
  • From: Alexander Staubo
• Re: How would you store read/unread topic status?
  • From: Andres Freund
• How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: same query in high number of times
  • From: Laurent Laborde
• Re: same query in high number of times
  • From: Laurent Laborde
• Re: same query in high number of times
  • From: Scott Carey
• Re: same query in high number of times
  • From: Peter Alban
• Re: same query in high number of times
  • From: Robert Haas
• Re: same query in high number of times
  • From: Justin Graf
• Re: same query in high number of times
  • From: Scott Marlowe
• Re: same query in high number of times
  • From: Peter Alban
• Re: same query in high number of times
  • From: Justin Graf
• Re: same query in high number of times
  • From: Grzegorz Jaśkiewicz
• Re: same query in high number of times
  • From: Justin Graf
• Re: same query in high number of times
  • From: Peter Alban
• Re: same query in high number of times
  • From: Robert Haas
• Re: same query in high number of times
  • From: Justin Graf
• same query in high number of times
  • From: Peter Alban
• Re: select max() much slower than select min()
  • From: David Rees
• Re: select max() much slower than select min()
  • From: Brian Cox
• Re: select max() much slower than select min()
  • From: David Rees
• Re: select max() much slower than select min()
  • From: Brian Cox
• Re: processor running queue - general rule of thumb?
  • From: Alan McKay
• Re: processor running queue - general rule of thumb?
  • From: Scott Marlowe
• Re: processor running queue - general rule of thumb?
  • From: justin
• processor running queue - general rule of thumb?
  • From: Alan McKay
• Re: select max() much slower than select min()
  • From: Greg Stark
• Re: 8.4 COPY performance regression on Solaris
  • From: Tom Lane
• Re: select max() much slower than select min()
  • From: Tom Lane
• Re: select max() much slower than select min()
  • From: Dave Dutcher
• Re: 8.4 COPY performance regression on Solaris
  • From: Kenneth Marshall
• Re: select max() much slower than select min()
  • From: Kevin Grittner
• Re: select max() much slower than select min()
  • From: Brian Cox
• Re: select max() much slower than select min()
  • From: Kevin Grittner
• select max() much slower than select min()
  • From: Brian Cox
• Re: Index Scan taking long time
  • From: Bryce Ewing
• Re: Strange performance response for high load times
  • From: Kevin Grittner
• Re: Strange performance response for high load times
  • From: Peter Alban
• Re: Strange performance response for high load times
  • From: Kenneth Marshall
• Re: performance with query
  • From: Kevin Grittner
• Re: Strange performance response for high load times
  • From: Peter Alban
• Re: performance with query
  • From: Tom Lane
• Re: performance with query
  • From: Kevin Grittner
• Re: Strange performance response for high load times
  • From: Kenneth Marshall
• Strange performance response for high load times
  • From: Peter Alban
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Grzegorz Jaśkiewicz
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: very slow selects on a small table
  • From: Grzegorz Jaśkiewicz
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: enum for performance?
  • From: Merlin Moncure
• Re: performance with query
  • From: Alberto Dalmaso
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: Index Scan taking long time
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: enum for performance?
  • From: Tom Lane
• enum for performance?
  • From: Whit Armstrong
• Re: Index Scan taking long time
  • From: Bryce Ewing
• very slow selects on a small table
  • From: Brian Cox
• Re: Performance issue - 2 linux machines, identical configs, different performance
  • From: Mark Steben
• Re: Performance issue - 2 linux machines, identical configs, different performance
  • From: Dave Dutcher
• Re: Performance issue - 2 linux machines, identical configs, different performance
  • From: Robert Haas
• Performance issue - 2 linux machines, identical configs, different performance
  • From: Mark Steben
• Re: performance with query
  • From: Kevin Grittner
• Re: Speeding up a query.
  • From: Hartman, Matthew
• Re: performance with query
  • From: Alberto Dalmaso
• Re: Speeding up a query.
  • From: Tom Lane
• Re: Speeding up a query.
  • From: Hartman, Matthew
• Re: Speeding up a query.
  • From: Hartman, Matthew
• Re: Speeding up a query.
  • From: Kevin Grittner
• Re: performance with query
  • From: Kevin Grittner
• Re: Index Scan taking long time
  • From: Tom Lane
• Re: Speeding up a query.
  • From: Merlin Moncure
• Re: GiST index performance
  • From: Heikki Linnakangas
• Re: Speeding up a query.
  • From: Alberto Dalmaso
• Re: Speeding up a query.
  • From: Grzegorz Jaśkiewicz
• Re: 8.4 COPY performance regression on Solaris
  • From: Stefan Kaltenbrunner
• Re: Speeding up a query.
  • From: Albe Laurenz
• Re: performance with query (OT)
  • From: Albe Laurenz
• Re: performance with query
  • From: Alberto Dalmaso
• 8.4 COPY performance regression on Solaris
  • From: Alan Li
• Re: Index Scan taking long time
  • From: Scott Marlowe
• Re: Yet another slow nested loop
  • From: Robert Haas
• Re: High cost of ... where ... not in (select ...)
  • From: Tom Lane
• Index Scan taking long time
  • From: Bryce Ewing
• Re: High cost of ... where ... not in (select ...)
  • From: Aaron Turner
• Re: High cost of ... where ... not in (select ...)
  • From: Aaron Turner
• Re: High cost of ... where ... not in (select ...)
  • From: Robert Haas
• Re: High cost of ... where ... not in (select ...)
  • From: Aaron Turner
• Re: High cost of ... where ... not in (select ...)
  • From: Robert Haas
• Re: High cost of ... where ... not in (select ...)
  • From: Aaron Turner
• Re: High cost of ... where ... not in (select ...)
  • From: Alvaro Herrera
• High cost of ... where ... not in (select ...)
  • From: Aaron Turner
• Performance discrepancy
  • From: Mark Steben
• Re: Speeding up a query.
  • From: Anthony Presley
• Speeding up a query.
  • From: Hartman, Matthew
• Re: performance with query
  • From: Alberto Dalmaso
• Re: performance with query
  • From: Alberto Dalmaso
• Re: performance with query
  • From: Tom Lane
• Re: performance with query
  • From: Kevin Grittner
• Re: performance with query
  • From: Alberto Dalmaso
• Re: performance with query
  • From: Kevin Grittner
• Re: performance with query
  • From: Alberto Dalmaso
• Re: performance with query
  • From: Kevin Grittner
• Re: performance with query
  • From: Tom Lane
• Re: Yet another slow nested loop
  • From: Alexander Staubo
• Re: performance with query
  • From: Alberto Dalmaso
• Re: performance with query
  • From: Kevin Grittner
• Re: performance with query
  • From: Matthew Wakeling
• Re: performance with query
  • From: Alberto Dalmaso
• Re: Yet another slow nested loop
  • From: Tom Lane
• Re: performance with query
  • From: Kevin Grittner
• Re: performance with query
  • From: Joshua Tolley
• Re: Yet another slow nested loop
  • From: Alexander Staubo
• Re: Yet another slow nested loop
  • From: Dave Dutcher
• performance with query
  • From: Alberto Dalmaso
• Yet another slow nested loop
  • From: Alexander Staubo
• Re: Postgres connection status as BIND
  • From: Alan Hodgson
• Re: Postgres connection status as BIND
  • From: Tom Lane
• Postgres connection status as BIND
  • From: Nimesh Satam
• Re: Censorship
  • From: Dan Langille
• Re: what server stats to track / monitor ?
  • From: Joshua Tolley
• Re: what server stats to track / monitor ?
  • From: Rauan Maemirov
• Re: what server stats to track / monitor ?
  • From: Alan McKay
• Re: what server stats to track / monitor ?
  • From: Alan McKay
• Re: what server stats to track / monitor ?
  • From: Joshua Tolley
• what server stats to track / monitor ?
  • From: Alan McKay
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Greg Sabino Mullane
• Re: GiST index performance
  • From: Adam Gundy
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Shaul Dar
• Re: Best way to load test a postgresql server
  • From: Erik Aronesty
• Re: GiST index performance
  • From: Tom Lane
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Joshua D. Drake
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Greg Sabino Mullane
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Joshua D. Drake
• Re: GiST index performance
  • From: Tom Lane
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Dimitri Fontaine
• Re: GiST index performance
  • From: Tom Lane
• Postgres replication: dump/restore, PITR, Slony,...?
  • From: Shaul Dar
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Hosted servers with good DB disk performance?
  • From: Dimitri Fontaine
• Re: Looking for installations with a large number of concurrent users
  • From: David Kerr
• Re: Why is my stats collector so busy?
  • From: Tom Lane
• Re: GiST index performance
  • From: Tom Lane
• Re: Looking for installations with a large number of concurrent users
  • From: Kevin Grittner
• Re: Explaining an EXPLAIN.
  • From: Matthew Wakeling
• Re: Explaining an EXPLAIN.
  • From: Tom Lane
• Re: EXPLAIN understanding? (restarted from Censorship)
  • From: Richard Huxton
• EXPLAIN understanding? (restarted from Censorship)
  • From: Richard Huxton
• Explaining an EXPLAIN.
  • From: Matthew Wakeling
• Re: Censorship
  • From: Tom Lane
• Re: Censorship
  • From: Matthew Wakeling
• Re: Censorship
  • From: Scott Mead
• Re: Censorship
  • From: Matthew Wakeling
• Re: Censorship
  • From: Gurjeet Singh
• Re: Censorship
  • From: Matthew Wakeling
• Re: Censorship
  • From: Guillaume Cottenceau
• Censorship
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Hosted servers with good DB disk performance?
  • From: Markus Wanner
• Re: Why is my stats collector so busy?
  • From: Laszlo Nagy
• Looking for installations with a large number of concurrent users
  • From: David Kerr
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Best way to load test a postgresql server
  • From: Tom Lane
• Re: Best way to load test a postgresql server
  • From: Shaul Dar
• Re: Pointers needed on optimizing slow SQL statements
  • From: Dimitri Fontaine
• Re: Pointers needed on optimizing slow SQL statements
  • From: Віталій Тимчишин
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Why is my stats collector so busy?
  • From: Laszlo Nagy
• Re: Pointers needed on optimizing slow SQL statements
  • From: Robert Haas
• Re: Pointers needed on optimizing slow SQL statements
  • From: Dimitri Fontaine
• Postgres installation for Performance
  • From: S Arvind
• Re: Vacuum ALL FULL
  • From: S Arvind
• Re: Vacuum ALL FULL
  • From: Tom Lane
• Re: Vacuum ALL FULL
  • From: S Arvind
• Re: Vacuum ALL FULL
  • From: Tom Lane
• Re: Vacuum ALL FULL
  • From: S Arvind
• Re: Vacuum ALL FULL
  • From: S Arvind
• Re: Vacuum ALL FULL
  • From: Tom Lane
• Re: Vacuum ALL FULL
  • From: S Arvind
• Vacuum ALL FULL
  • From: S Arvind
• Re: Pointers needed on optimizing slow SQL statements
  • From: Simon Riggs
• Re: degenerate performance on one server of 3
  • From: Robert Haas
• Re: Bad Plan for Questionnaire-Type Query
  • From: Robert Haas
• Re: degenerate performance on one server of 3
  • From: Erik Aronesty
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Bad Plan for Questionnaire-Type Query
  • From: Josh Berkus
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Scalability in postgres
  • From: Robert Haas
• Re: GiST index performance
  • From: Robert Haas
• Re: Why is my stats collector so busy?
  • From: Robert Schnabel
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Craig James
• Re: Scalability in postgres
  • From: Robert Haas
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Why is my stats collector so busy?
  • From: Merlin Moncure
• Re: Why is my stats collector so busy?
  • From: Tom Lane
• Re: Why is my stats collector so busy?
  • From: Bruce Momjian
• Why is my stats collector so busy?
  • From: Laszlo Nagy
• Re: Scalability in postgres
  • From: Mark Mielke
• Re: Scalability in postgres
  • From: david
• Re: Scalability in postgres
  • From: david
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Mark Mielke
• Re: Scalability in postgres
  • From: Robert Haas
• Re: Scalability in postgres
  • From: david
• Re: Scalability in postgres
  • From: Scott Carey
• Re: Scalability in postgres
  • From: david
• Re: Scalability in postgres
  • From: Mark Mielke
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Scalability in postgres
  • From: James Mansion
• Re: Pointers needed on optimizing slow SQL statements
  • From: Josh Berkus
• Re: Scalability in postgres
  • From: Robert Haas
• Re: degenerate performance on one server of 3
  • From: Scott Carey
• Re: Scalability in postgres
  • From: Scott Carey
• Re: degenerate performance on one server of 3
  • From: Scott Carey
• Re: Query plan issues - volatile tables
  • From: Craig James
• GiST index performance
  • From: Matthew Wakeling
• Re: degenerate performance on one server of 3
  • From: Robert Haas
• Re: degenerate performance on one server of 3
  • From: Erik Aronesty
• Re: Scalability in postgres
  • From: Robert Haas
• Re: Scalability in postgres
  • From: Marc Cousin
• Re: Pointers needed on optimizing slow SQL statements
  • From: Scott Marlowe
• Re: degenerate performance on one server of 3
  • From: Reid Thompson
• Re: Pointers needed on optimizing slow SQL statements
  • From: Janine Sisk
• Query plan issues - volatile tables
  • From: Brian Herlihy
• Re: Pointers needed on optimizing slow SQL statements
  • From: Robert Haas
• Re: Best way to load test a postgresql server
  • From: Greg Smith
• Re: Pointers needed on optimizing slow SQL statements
  • From: Janine Sisk
• Re: Pointers needed on optimizing slow SQL statements
  • From: Tom Lane
• Pointers needed on optimizing slow SQL statements
  • From: Janine Sisk
• Re: degenerate performance on one server of 3
  • From: Tom Lane
• Re: Scalability in postgres
  • From: Scott Carey
• Re: degenerate performance on one server of 3
  • From: Erik Aronesty
• Re: Scalability in postgres
  • From: Robert Haas
• Re: Scalability in postgres
  • From: Scott Carey
• Re: Scalability in postgres
  • From: Dimitri
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Scalability in postgres
  • From: Dimitri
• Re: poor performing plan from analyze vs. fast default plan pre-analyze on new database
  • From: Scott Carey
• Re: poor performing plan from analyze vs. fast default plan pre-analyze on new database
  • From: Tom Lane
• Re: poor performing plan from analyze vs. fast default plan pre-analyze on new database
  • From: Grzegorz Jaśkiewicz
• poor performing plan from analyze vs. fast default plan pre-analyze on new database
  • From: Davin Potts
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Best way to load test a postgresql server
  • From: Kenneth Cox
• Re: Best way to load test a postgresql server
  • From: Shaul Dar
• Re: Scalability in postgres
  • From: James Mansion
• Re: Best way to load test a postgresql server
  • From: Dimitri Fontaine
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Best way to load test a postgresql server
  • From: Shaul Dar
• Re: Best way to load test a postgresql server
  • From: Kenneth Cox
• Re: Using index for bitwise operations?
  • From: Matthew Wakeling
• Re: Very inefficient query plan with disjunction in WHERE clause
  • From: Matthew Wakeling
• Re: Very inefficient query plan with disjunction in WHERE clause
  • From: Matthew Wakeling
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Віталій Тимчишин
• Re: Best way to load test a postgresql server
  • From: Dimitri Fontaine
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Ron Mayer
• Re: Vacuuming technique doubt
  • From: Robert Haas
• Re: Vacuuming technique doubt
  • From: Kevin Grittner
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Unexpected query plan results
  • From: Dave Dutcher
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Scalability in postgres
  • From: Scott Carey
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Vacuuming technique doubt
  • From: S Arvind
• Re: Best way to load test a postgresql server
  • From: Alan McKay
• Re: Very inefficient query plan with disjunction in WHERE clause
  • From: Віталій Тимчишин
• Re: Using index for bitwise operations?
  • From: Tom Lane
• Re: Using index for bitwise operations?
  • From: Richard Huxton
• Very inefficient query plan with disjunction in WHERE clause
  • From: Koen Martens
• Best way to load test a postgresql server
  • From: Peter Sheats
• Using index for bitwise operations?
  • From: Shaul Dar
• Re: Vacuuming technique doubt
  • From: Greg Smith
• Re: degenerate performance on one server of 3
  • From: Tom Lane
• Re: Postgresql cache (memory) performance + how to warm up the cache
  • From: Greg Smith
• Re: Vacuuming technique doubt
  • From: David Rees
• Postgresql cache (memory) performance + how to warm up the cache
  • From: Shaul Dar
• Vacuuming technique doubt
  • From: S Arvind
• Re: degenerate performance on one server of 3
  • From: Erik Aronesty
• Re: degenerate performance on one server of 3
  • From: Tom Lane
• Re: degenerate performance on one server of 3
  • From: Craig Ringer
• Re: autovacuum hung?
  • From: Tom Lane
• Re: autovacuum hung?
  • From: Tom Lane
• Re: autovacuum hung?
  • From: Brian Cox
• Re: autovacuum hung?
  • From: Tom Lane
• Re: autovacuum hung?
  • From: Brian Cox
• Re: autovacuum hung?
  • From: Tom Lane
• Re: autovacuum hung?
  • From: Brian Cox
• Re: Scalability in postgres
  • From: Fabrix
• Re: degenerate performance on one server of 3
  • From: Tom Lane
• degenerate performance on one server of 3
  • From: Erik Aronesty
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Greg Smith
• Re: autovacuum hung?
  • From: Tom Lane
• Re: Scalability in postgres
  • From: Scott Carey
• Re: autovacuum hung?
  • From: Brian Cox
• Re: autovacuum hung?
  • From: Alvaro Herrera
• autovacuum hung?
  • From: Brian Cox
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Scalability in postgres
  • From: Scott Mead
• Re: Scalability in postgres
  • From: Fabrix
• Re: Unexpected query plan results
  • From: Scott Mead
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Scott Mead
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Fabrix
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Unexpected query plan results
  • From: Dave Dutcher
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Unexpected query plan results
  • From: Dave Dutcher
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Grzegorz Jaśkiewicz
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Grzegorz Jaśkiewicz
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Grzegorz Jaśkiewicz
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Grzegorz Jaśkiewicz
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Flavio Henrique Araque Gurgel
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Fabrix
• Re: Scalability in postgres
  • From: Flavio Henrique Araque Gurgel
• Re: Continuent (was: Postgres Clustering)
  • From: Flavio Henrique Araque Gurgel
• Unexpected query plan results
  • From: Anne Rosset
• Re: Scalability in postgres
  • From: Fabrix
• Re: Scalability in postgres
  • From: Fabrix
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Scott Mead
• Re: Scalability in postgres
  • From: Fabrix
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: David Rees
• Re: Storing sensor data
  • From: Greg Jaman
• Re: Storing sensor data
  • From: Greg Jaman
• Scalability in postgres
  • From: Fabrix
• Re: Storing sensor data
  • From: Kenneth Marshall
• Continuent (was: Postgres Clustering)
  • From: Alan McKay
• Re: Storing sensor data
  • From: Grzegorz Jaśkiewicz
• Re: Storing sensor data
  • From: Alexander Staubo
• Re: Storing sensor data
  • From: Ivan Voras
• Re: Storing sensor data
  • From: Ivan Voras
• Re: Storing sensor data
  • From: Kenneth Marshall
• Re: Storing sensor data
  • From: Ivan Voras
• Re: Storing sensor data
  • From: Ivan Voras
• Re: Storing sensor data
  • From: Alexander Staubo
• Re: Storing sensor data
  • From: Nikolas Everett
• Re: Storing sensor data
  • From: Heikki Linnakangas
• Storing sensor data
  • From: Ivan Voras
• Re: Postgres Clustering
  • From: Alan McKay
• Re: Postgres Clustering
  • From: Dimitri Fontaine
• Re: Postgres Clustering
  • From: Eddy Ernesto Baños Fernández
• Re: Postgres Clustering
  • From: Daniel van Ham Colchete
• Re: Postgres Clustering
  • From: Scott Mead
• Re: Postgres Clustering
  • From: Thomas Kellerer
• Postgres Clustering
  • From: Alan McKay
• Re: Improve Query
  • From: Heikki Linnakangas
• Re: Improve Query
  • From: Zach Calvert
• Re: Improve Query
  • From: Grzegorz Jaśkiewicz
• Re: Improve Query
  • From: Zach Calvert
• Re: Improve Query
  • From: Nikolas Everett
• Re: Hosted servers with good DB disk performance?
  • From: Scott Mead
• Re: running bonnie++
  • From: Greg Smith
• Re: Hosted servers with good DB disk performance?
  • From: David Wall
• Re: Improve Query
  • From: Grzegorz Jaśkiewicz
• Improve Query
  • From: Zach Calvert
• Re: Hosted servers with good DB disk performance?
  • From: Joshua D. Drake
• Re: running bonnie++
  • From: Glyn Astill
• running bonnie++
  • From: Alan McKay
• L
  • From: Thomas Kellerer
• Re: Bytea updation
  • From: Albe Laurenz
• Re: Hosted servers with good DB disk performance?
  • From: Dimitri Fontaine
• [no subject]
  • From: ramasubramanian
• Bytea updation
  • From: ramasubramanian
• Re: Hosted servers with good DB disk performance?
  • From: Alex Adriaanse
• Re: Hosted servers with good DB disk performance?
  • From: Erik Aronesty
• Re: Hosted servers with good DB disk performance?
  • From: Ron Mayer
• Re: Hosted servers with good DB disk performance?
  • From: Greg Smith
• Re: Hosted servers with good DB disk performance?
  • From: Scott Marlowe
• Re: Hosted servers with good DB disk performance?
  • From: Scott Carey
• Re: Hosted servers with good DB disk performance?
  • From: Scott Carey
• Re: Problems with autovacuum
  • From: Scott Marlowe
• Re: Hosted servers with good DB disk performance?
  • From: Scott Marlowe
• Re: Hosted servers with good DB disk performance?
  • From: Scott Carey
• Re: Hosted servers with good DB disk performance?
  • From: Josh Berkus
• Re: Hosted servers with good DB disk performance?
  • From: Greg Smith
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Hosted servers with good DB disk performance?
  • From: Dave Page
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Hosted servers with good DB disk performance?
  • From: Joshua D. Drake
• Re: Hosted servers with good DB disk performance?
  • From: Jerry Champlin
• Re: Hosted servers with good DB disk performance?
  • From: Marcin Stępnicki
• Re: Hosted servers with good DB disk performance?
  • From: Craig James
• Hosted servers with good DB disk performance?
  • From: Greg Smith
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Łukasz Jagiełło
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Putting tables or indexes in SSD or RAM: avoiding double caching?
  • From: Kenny Gorman
• Re: Problems with autovacuum
  • From: Grzegorz Jaśkiewicz
• Re: Problems with autovacuum
  • From: Łukasz Jagiełło
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Łukasz Jagiełło
• Re: Problems with autovacuum
  • From: Łukasz Jagiełło
• Re: Problems with autovacuum
  • From: Scott Marlowe
• Re: Problems with autovacuum
  • From: Grzegorz Jaśkiewicz
• Re: Problems with autovacuum
  • From: Scott Marlowe
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Putting tables or indexes in SSD or RAM: avoiding double caching?
  • From: Shaul Dar
• Problems with autovacuum
  • From: Łukasz Jagiełło
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: Full statement logging problematic on larger machines?
  • From: Frank Joerdens
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: raid10 hard disk choice
  • From: Robert Schnabel
• Re: raid10 hard disk choice
  • From: Greg Smith
• Re: raid10 hard disk choice
  • From: Scott Marlowe
• Re: raid10 hard disk choice
  • From: Greg Smith
• Re: raid10 hard disk choice
  • From: Robert Schnabel
• Re: raid10 hard disk choice
  • From: Linos
• Re: raid10 hard disk choice
  • From: Greg Smith
• Re: raid10 hard disk choice
  • From: Greg Smith
• Re: raid10 hard disk choice
  • From: Scott Carey
• Re: raid10 hard disk choice
  • From: Robert Haas
• Re: raid10 hard disk choice
  • From: Scott Carey
• Re: raid10 hard disk choice
  • From: Scott Marlowe
• Re: raid10 hard disk choice
  • From: Robert Haas
• Re: raid10 hard disk choice
  • From: Craig James
• Re: raid10 hard disk choice
  • From: Scott Marlowe
• Re: raid10 hard disk choice
  • From: Joshua D. Drake
• Re: query planner uses sequencial scan instead of index scan
  • From: Tom Lane
• Re: raid10 hard disk choice
  • From: Robert Schnabel
• Re: raid10 hard disk choice
  • From: Merlin Moncure
• Re: raid10 hard disk choice
  • From: Matthew Wakeling
• raid10 hard disk choice
  • From: Linos
• query planner uses sequencial scan instead of index scan
  • From: Daniel Ferreira
• PQisBusy behaving strangely
  • From: Richard Yen
• Re: postgresql.conf suggestions?
  • From: Greg Smith
• Re: postgresql.conf suggestions?
  • From: Robert Haas
• postgresql.conf suggestions?
  • From: Kobby Dapaah
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dave Dutcher
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: superlative missuse
  • From: Craig James
• Re: superlative missuse
  • From: David Wilson
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: UNION ALL and sequential scans
  • From: Tom Lane
• Re: UNION ALL and sequential scans
  • From: Mathieu De Zutter
• Re: UNION ALL and sequential scans
  • From: Tom Lane
• UNION ALL and sequential scans
  • From: Brad Jorsch
• Re: increase index performance
  • From: Ow Mun Heng
• Re: increase index performance
  • From: Matthew Wakeling
• Re: AMD Shanghai versus Intel Nehalem
  • From: Greg Smith
• Re: increase index performance
  • From: Ow Mun Heng
• Re: AMD Shanghai versus Intel Nehalem
  • From: Arjen van der Meijden
• Re: Any better plan for this query?..
  • From: Dimitri Fontaine
• Re: increase index performance
  • From: Thomas Finneid
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: superlative missuse
  • From: Angel Alvarez
• Re: superlative missuse
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Kevin Grittner
• Re: superlative missuse
  • From: Chris Browne
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Greg Stark
• Re: Any better plan for this query?..
  • From: Kevin Grittner
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Stefan Kaltenbrunner
• Re: increase index performance
  • From: Matthew Wakeling