Postgres Performance Date Index
Thread Index
[
Prev Page
][
Next Page
]
Re: PostgreSQL vs MySQL, and FreeBSD
From
: Sebastian Hennebrueder
Re: PostgreSQL vs MySQL, and FreeBSD
From
: Jonah H. Harris
PostgreSQL vs MySQL, and FreeBSD
From
: Ivan Voras
Re: dell versus hp
From
: Florian Weimer
Re: [HACKERS] Estimation problem with a LIKE clause containing a /
From
: Gregory Stark
Re: [HACKERS] Estimation problem with a LIKE clause containing a /
From
: Guillaume Smet
Re: Help understanding stat numbers
From
: Tom Lane
Help understanding stat numbers
From
: Chris Hoover
Re: Hardware for PostgreSQL
From
: Robert Treat
Re: How to avoid hashjoin and mergejoin
From
: Carlo Stonebanks
Re: [HACKERS] Estimation problem with a LIKE clause containing a /
From
: Tom Lane
Re: Join performance
From
: Tom Lane
Re: Estimation problem with a LIKE clause containing a /
From
: Tom Lane
Re: Join performance
From
: Tom Lane
Re: Join performance
From
: Tom Lane
Re: Join performance
From
: Tom Lane
Re: Join performance
From
: Tom Lane
Re: dell versus hp
From
: Scott Marlowe
Re: Estimation problem with a LIKE clause containing a /
From
: Gregory Stark
Re: Join performance
From
: Steinar H. Gunderson
Join performance
From
: Pepe Barbe
Re: dell versus hp
From
: Vivek Khera
Re: dell versus hp
From
: Alan Hodgson
Re: dell versus hp
From
: Kevin Grittner
Re: dell versus hp
From
: Dimitri Fontaine
Re: dell versus hp
From
: Scott Marlowe
Re: Estimation problem with a LIKE clause containing a /
From
: Tom Lane
Re: dell versus hp
From
: Vivek Khera
Re: Need to run CLUSTER to keep performance
From
: Chris Browne
Re: hp ciss on freebsd
From
: Vivek Khera
Re: dell versus hp
From
: Vivek Khera
Re: Need to run CLUSTER to keep performance
From
: Tom Lane
Re: Estimation problem with a LIKE clause containing a /
From
: Guillaume Smet
Re: Need to run CLUSTER to keep performance
From
: Rafael Martinez
Re: Need to run CLUSTER to keep performance
From
: Bill Moran
Re: Need to run CLUSTER to keep performance
From
: Heikki Linnakangas
Re: Need to run CLUSTER to keep performance
From
: Rafael Martinez
Re: Estimation problem with a LIKE clause containing a /
From
: Tom Lane
Re: Need to run CLUSTER to keep performance
From
: Alvaro Herrera
Re: Need to run CLUSTER to keep performance
From
: Rafael Martinez
Re: Need to run CLUSTER to keep performance
From
: Tomáš Vondra
Re: Need to run CLUSTER to keep performance
From
: Heikki Linnakangas
Need to run CLUSTER to keep performance
From
: Rafael Martinez
Re: Estimation problem with a LIKE clause containing a /
From
: Guillaume Smet
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Mark Kirkwood
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Gregory Stark
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Luke Lonergan
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Mark Kirkwood
Re: Estimation problem with a LIKE clause containing a /
From
: Guillaume Smet
Re: Estimation problem with a LIKE clause containing a /
From
: Guillaume Smet
Re: Estimation problem with a LIKE clause containing a /
From
: Tom Lane
Re: Estimation problem with a LIKE clause containing a /
From
: Tom Lane
Re: Estimation problem with a LIKE clause containing a /
From
: Guillaume Smet
Re: Estimation problem with a LIKE clause containing a /
From
: Tom Lane
Re: index stat
From
: Kevin Grittner
Re: Estimation problem with a LIKE clause containing a /
From
: Guillaume Smet
Re: Estimation problem with a LIKE clause containing a /
From
: Alexander Staubo
Estimation problem with a LIKE clause containing a /
From
: Guillaume Smet
Subpar Execution Plan
From
: Jens-Wolfhard Schicke
Re: dell versus hp
From
: Greg Smith
Re: dell versus hp
From
: Dimitri Fontaine
Re: dell versus hp
From
: Tore Halset
Re: dell versus hp
From
: Tore Halset
Re: dell versus hp
From
: Stephen Frost
Re: dell versus hp
From
: Dimitri Fontaine
Re: dell versus hp
From
: Claus Guttesen
dell versus hp
From
: Tore Halset
Re: Is ANALYZE transactional?
From
: Tom Lane
Is ANALYZE transactional?
From
: Craig James
Re: Database connections and stored procs (functions)
From
: Merlin Moncure
Re: Which index methodology is better?-
From
: Heikki Linnakangas
Re: Which index methodology is better?-
From
: Tom Lane
Which index methodology is better?-
From
: Chris Hoover
Re: Migrating to 8.3 - checkpoints and background writer
From
: Erik Jones
Training Recommendations
From
: Campbell, Lance
index stat
From
: Campbell, Lance
Re: hp ciss on freebsd
From
: Greg Smith
Re: hp ciss on freebsd
From
: Jeff Trout
Database connections and stored procs (functions)
From
: Radhika S
hp ciss on freebsd
From
: Claus Guttesen
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Gregory Stark
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Mark Kirkwood
Re: Migrating to 8.3 - checkpoints and background writer
From
: Greg Smith
Re: Migrating to 8.3 - checkpoints and background writer
From
: Steinar H. Gunderson
Migrating to 8.3 - checkpoints and background writer
From
: Greg Smith
Re: Postgresql.conf Settings
From
: Heikki Linnakangas
Re: Postgresql.conf Settings
From
: smiley2211
Re: Postgresql.conf Settings
From
: Scott Marlowe
Re: Unfortunate expansion of composite types in union
From
: Jens-Wolfhard Schicke
Postgresql.conf Settings
From
: smiley2211
Re: Union within View vs.Union of Views
From
: Jeff Larsen
Re: Union within View vs.Union of Views
From
: Jeff Larsen
Re: "MixedCase sensitive quoted" names
From
: Tom Lane
Re: Union within View vs.Union of Views
From
: Tom Lane
"MixedCase sensitive quoted" names
From
: Whatever Deep
Re: Union within View vs.Union of Views
From
: Heikki Linnakangas
Re: Union within View vs.Union of Views
From
: Mark Mielke
Union within View vs.Union of Views
From
: Jeff Larsen
Re: [Fwd: Re: Outer joins and Seq scans]
From
: Alvaro Herrera
Re: Hardware for PostgreSQL (RAID configurations)
From
: Mark F
[no subject]
From
: Mark F
Re: Hardware for PostgreSQL
From
: Jurgen Haan
Re: select max(field) from table much faster with a group by clause?
From
: Palle Girgensohn
Re: Unfortunate expansion of composite types in union
From
: Pavel Stehule
Unfortunate expansion of composite types in union
From
: Jens-Wolfhard Schicke
Re: select max(field) from table much faster with a group by clause?
From
: hubert depesz lubaczewski
Re: How to avoid hashjoin and mergejoin
From
: Carlo Stonebanks
Re: hardware for PostgreSQL
From
: Scott Marlowe
hardware for PostgreSQL
From
: Mark Floyd
Re: Hardware for PostgreSQL
From
: Ow Mun Heng
Re: How to avoid hashjoin and mergejoin
From
: Tom Lane
Re: How to avoid hashjoin and mergejoin
From
: Scott Marlowe
How to avoid hashjoin and mergejoin
From
: Carlo Stonebanks
Re: Hardware for PostgreSQL
From
: Steve Crawford
Re: Hardware for PostgreSQL
From
: Steve Crawford
Re: select max(field) from table much faster with a group by clause?
From
: Gregory Stark
Re: select max(field) from table much faster with a group by clause?
From
: Tom Lane
Re: select max(field) from table much faster with a group by clause?
From
: Scott Marlowe
Re: select max(field) from table much faster with a group by clause?
From
: Palle Girgensohn
Re: select max(field) from table much faster with a group by clause?
From
: Tom Lane
Re: select max(field) from table much faster with a group by clause?
From
: Palle Girgensohn
Re: [Fwd: Re: Outer joins and Seq scans]
From
: Sami Dalouche
Re: select max(field) from table much faster with a group by clause?
From
: Palle Girgensohn
Re: select max(field) from table much faster with a group by clause?
From
: Tom Lane
Re: [Fwd: Re: Outer joins and Seq scans]
From
: Tom Lane
select max(field) from table much faster with a group by clause?
From
: Palle Girgensohn
Re: Hardware for PostgreSQL
From
: Adam Tauno Williams
Re: hardware and For PostgreSQL
From
: Joe Uhl
Re: Hardware for PostgreSQL
From
: Magnus Hagander
Re: Hardware for PostgreSQL
From
: Ow Mun Heng
Re: hardware and For PostgreSQL
From
: Magnus Hagander
Re: Hardware for PostgreSQL
From
: Magnus Hagander
Re: Hardware for PostgreSQL
From
: Magnus Hagander
Re: Hardware for PostgreSQL
From
: Ow Mun Heng
Re: Hardware for PostgreSQL
From
: Ericson Smith
Re: hardware and For PostgreSQL
From
: Paul Lambert
Re: [Fwd: Re: Outer joins and Seq scans]
From
: Tom Lane
Re: hardware and For PostgreSQL
From
: Joshua D. Drake
[Fwd: Re: Outer joins and Seq scans]
From
: Sami Dalouche
Re: hardware and For PostgreSQL
From
: Ron St-Pierre
Re: Hardware for PostgreSQL
From
: Tomas Vondra
Re: Hardware for PostgreSQL
From
: Kevin Grittner
Re: tables with 300+ partitions
From
: Pablo Alcaraz
Re: hardware and For PostgreSQL
From
: Joe Uhl
Re: Hardware for PostgreSQL
From
: Arjen van der Meijden
Re: Hardware for PostgreSQL
From
: Magnus Hagander
Re: tables with 300+ partitions
From
: Scott Marlowe
Re: hardware and For PostgreSQL
From
: Ben
Hardware for PostgreSQL
From
: Ketema
Re: tables with 300+ partitions
From
: Tomáš Vondra
Re: tables with 300+ partitions
From
: Steven Flatt
Re: hardware and For PostgreSQL
From
: Scott Marlowe
hardware and For PostgreSQL
From
: Ketema Harris
Re: tables with 300+ partitions
From
: Pablo Alcaraz
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Luke Lonergan
Re: Two fast queries get slow when combined
From
: cluster
Re: Two fast queries get slow when combined
From
: cluster
Re: Optimizing PostgreSQL for Windows
From
: Christian Rengstl
Re: Two fast queries get slow when combined
From
: Tom Lane
Re: Two fast queries get slow when combined
From
: Heikki Linnakangas
Two fast queries get slow when combined
From
: cluster
Re: tables with 300+ partitions
From
: Steven Flatt
Re: tables with 300+ partitions
From
: Heikki Linnakangas
Re: Optimizing PostgreSQL for Windows
From
: Guillaume Lelarge
tables with 300+ partitions
From
: Pablo Alcaraz
Re: Improving Query
From
: Ketema Harris
Re: Optimizing PostgreSQL for Windows
From
: Dave Dutcher
Re: Improving Query
From
: Tom Lane
Re: Optimizing PostgreSQL for Windows
From
: Marc Schablewski
Re: Improving Query
From
: Ketema Harris
Re: Improving Query
From
: Ketema Harris
Re: Improving Query
From
: Michael Glaesemann
Optimizing PostgreSQL for Windows
From
: Christian Rengstl
Re: Improving Query
From
: Richard Huxton
Improving Query
From
: Ketema
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Gregory Stark
High Availability and Load Balancing
From
: ruben
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Tom Lane
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Mark Kirkwood
Re: Suggestions on an update query
From
: Scott Marlowe
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Luke Lonergan
Re: Suggestions on an update query
From
: Campbell, Lance
Re: Append Cost in query planners
From
: Heikki Linnakangas
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Gregory Stark
Re: Append Cost in query planners
From
: Nimesh Satam
Re: Outer joins and Seq scans
From
: Cédric Villemain
Re: Append Cost in query planners
From
: Heikki Linnakangas
Re: Outer joins and Seq scans
From
: Richard Huxton
Re: Append Cost in query planners
From
: Nimesh Satam
Re: Outer joins and Seq scans
From
: Dimitri Fontaine
Re: Outer joins and Seq scans
From
: Tom Lane
Re: Outer joins and Seq scans
From
: Sami Dalouche
Re: Outer joins and Seq scans
From
: Tom Lane
Outer joins and Seq scans
From
: Sami Dalouche
Re: Append Cost in query planners
From
: Heikki Linnakangas
Re: partitioned table and ORDER BY indexed_field DESCLIMIT 1
From
: Simon Riggs
Re: partitioned table and ORDER BY indexed_field DESCLIMIT 1
From
: Tom Lane
Re: Append Cost in query planners
From
: Heikki Linnakangas
Append Cost in query planners
From
: Nimesh Satam
Re: partitioned table and ORDER BY indexed_field DESCLIMIT 1
From
: Simon Riggs
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Gregory Stark
Re: Speed difference between select ... union select ... and select from partitioned_table
From
: Pablo Alcaraz
Re: partitioned table and ORDER BY indexed_field DESCLIMIT 1
From
: Luke Lonergan
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Simon Riggs
Re: Speed difference between select ... union select ... and select from partitioned_table
From
: Simon Riggs
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Luke Lonergan
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Luke Lonergan
Re: Speed difference between select ... union select ... and select from partitioned_table
From
: Tom Lane
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Heikki Linnakangas
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Anton
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Tom Lane
Re: Speed difference between select ... union select ... and select from partitioned_table
From
: Pablo Alcaraz
Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
From
: Anton
Re: Suggestions on an update query
From
: Joshua D. Drake
Re: Suggestions on an update query
From
: Gregory Stark
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Jignesh K. Shah
Re: Suggestions on an update query
From
: Joshua D. Drake
Re: Speed difference between select ... union select ... and select from partitioned_table
From
: Gregory Stark
Re: Speed difference between select ... union select ... and select from partitioned_table
From
: Pablo Alcaraz
Re: Suggestions on an update query
From
: Gregory Stark
Re: Speed difference between select ... union select ... and select from partitioned_table
From
: Jeff Davis
Speed difference between select ... union select ... and select from partitioned_table
From
: Pablo Alcaraz
Re: Suggestions on an update query
From
: Campbell, Lance
Suggestions on an update query
From
: Campbell, Lance
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Tom Lane
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Jignesh K. Shah
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Jignesh K. Shah
Re: Bunching "transactions"
From
: Greg Smith
Re: Bunching "transactions"
From
: Jean-David Beyer
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Jignesh K. Shah
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Jignesh K. Shah
Re: 8.3beta1 testing on Solaris
From
: Jignesh K. Shah
Re: Bunching "transactions"
From
: Jean-David Beyer
Re: Finalizing commit taking very long
From
: Giulio Cesare Solaroli
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Gregory Stark
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Tom Lane
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Josh Berkus
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Tom Lane
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Gregory Stark
Re: 8.3beta1 testing on Solaris
From
: Gregory Stark
Re: Bunching "transactions"
From
: Chris Browne
Re: [HACKERS] 8.3beta1 testing on Solaris
From
: Tom Lane
PostgreSQL 8.3beta1 on Solaris testing case study
From
: Jignesh K. Shah
8.3beta1 testing on Solaris
From
: Jignesh K. Shah
Re: Bunching "transactions"
From
: Jean-David Beyer
Re: Bunching "transactions"
From
: Chris Browne
Re: Bunching "transactions"
From
: Tom Lane
Re: Bunching "transactions"
From
: Heikki Linnakangas
Bunching "transactions"
From
: Jean-David Beyer
Re: Bunching "transactions"
From
: Erik Jones
Re: multiple apaches against single postgres database
From
: Tatsuo Ishii
Re: Finalizing commit taking very long
From
: Giulio Cesare Solaroli
Re: multiple apaches against single postgres database
From
: Kevin Grittner
Re: multiple apaches against single postgres database
From
: Sven Geisler
Re: Finalizing commit taking very long
From
: Tom Lane
Re: Finalizing commit taking very long
From
: Giulio Cesare Solaroli
Re: multiple apaches against single postgres database
From
: Gregory Stark
Re: 12 hour table vacuums
From
: Jean-David Beyer
Re: multiple apaches against single postgres database
From
: Michal Taborsky - Internet Mall
Re: Finalizing commit taking very long
From
: Tom Lane
multiple apaches against single postgres database
From
: Honza Novak
Finalizing commit taking very long
From
: Giulio Cesare Solaroli
Re: 12 hour table vacuums
From
: Harald Fuchs
Re: 12 hour table vacuums
From
: Alvaro Herrera
Re: 12 hour table vacuums
From
: Alvaro Herrera
Re: 12 hour table vacuums
From
: Simon Riggs
Re: 12 hour table vacuums
From
: Joshua D. Drake
Re: 12 hour table vacuums
From
: Ron St-Pierre
Re: 12 hour table vacuums
From
: Ron St-Pierre
Re: 12 hour table vacuums
From
: Ron St-Pierre
Re: 12 hour table vacuums
From
: Bill Moran
Re: 12 hour table vacuums
From
: Gregory Stark
Re: 12 hour table vacuums
From
: Ron St-Pierre
Re: 12 hour table vacuums
From
: Csaba Nagy
Re: 12 hour table vacuums
From
: Alvaro Herrera
Re: 12 hour table vacuums
From
: Tom Lane
Re: 12 hour table vacuums
From
: Bill Moran
12 hour table vacuums
From
: Ron St-Pierre
Re: Seqscan
From
: Nis Jørgensen
Re: Seqscan
From
: Adrian Demaestri
Re: How to improve speed of 3 table join &group (HUGE tables)
From
: Nis Jørgensen
Re: need help with a query
From
: Pavel Velikhov
Re: Seqscan
From
: Jeff Davis
Seqscan
From
: Adrian Demaestri
Re: Memory Settings....
From
: Kevin Grittner
Re: Memory Settings....
From
: Heikki Linnakangas
Re: Memory Settings....
From
: Ben
Re: Memory Settings....
From
: Peter Koczan
Memory Settings....
From
: Lee Keel
Re: need help with a query
From
: Jonah H. Harris
Re: [SQL] two queryes in a single tablescan
From
: Erik Jones
Re: need help with a query
From
: Pavel Velikhov
Re: [SQL] two queryes in a single tablescan
From
: Andreas Kretschmer
Re: [SQL] two queryes in a single tablescan
From
: Markus Schaber
Re: how to improve the performance of creating index
From
: Scott Marlowe
Re: need help with a query
From
: Tom Lane
Re: need help with a query
From
: Pavel Velikhov
Re: need help with a query
From
: Jonah H. Harris
need help with a query
From
: Pavel Velikhov
Re: how to improve the performance of creating index
From
: Heikki Linnakangas
Re: how to improve the performance of creating index
From
: Chris Browne
Re: how to improve the performance of creating index
From
: Heikki Linnakangas
how to improve the performance of creating index
From
: Yinan Li
Re: How to improve speed of 3 table join &group (HUGE tables)
From
: ismo . tuononen
Re: Incorrect estimates on columns
From
: Chris Kratz
Re: How to improve speed of 3 table join &group (HUGE tables)
From
: John Major
Re: How to improve speed of 3 table join &group (HUGE tables)
From
: John Major
Re: How to improve speed of 3 table join &group (HUGE tables)
From
: Heikki Linnakangas
Re: How to improve speed of 3 table join &group (HUGE tables)
From
: Nis Jørgensen
How to improve speed of 3 table join &group (HUGE tables)
From
: John Major
Re: Incorrect estimates on columns
From
: Nis Jørgensen
Re: Vacuum goes worse
From
: Stéphane Schildknecht
Re: Vacuum goes worse
From
: Stéphane Schildknecht
Re: two queryes in a single tablescan
From
: 李彦 Ian Li
Re: Shared Buffer setting in postgresql.conf
From
: Ow Mun Heng
Re: Incorrect estimates on columns
From
: Tom Lane
Re: Huge amount of memory consumed during transaction
From
: Tom Lane
Re: Huge amount of memory consumed during transaction
From
: Alvaro Herrera
Re: Incorrect estimates on columns
From
: Chris Kratz
Re: Incorrect estimates on columns
From
: Tom Lane
Re: Vacuum goes worse
From
: Scott Marlowe
Incorrect estimates on columns
From
: Chris Kratz
Re: Vacuum goes worse
From
: Alvaro Herrera
Re: Vacuum goes worse
From
: Tom Lane
Re: Vacuum goes worse
From
: Tom Lane
Re: Vacuum goes worse
From
: Stefano Dal Pra
Re: Vacuum goes worse
From
: Alvaro Herrera
Re: two queryes in a single tablescan
From
: Heikki Linnakangas
Re: two queryes in a single tablescan
From
: Stefano Dal Pra
Re: two queryes in a single tablescan
From
: Steinar H. Gunderson
Re: two queryes in a single tablescan
From
: Heikki Linnakangas
two queryes in a single tablescan
From
: Stefano Dal Pra
Re: Vacuum goes worse
From
: Stéphane Schildknecht
Re: using a stored proc that returns a result set in a complex SQL stmt
From
: Marcin Stępnicki
Re: Vacuum goes worse
From
: Joshua D. Drake
Re: Vacuum goes worse
From
: Tom Lane
Re: Vacuum goes worse
From
: Brian Herlihy
Re: Vacuum goes worse
From
: Tom Lane
Re: Autovacuum running out of memory
From
: 李彦 Ian Li
Re: Vacuum goes worse
From
: Scott Marlowe
Re: Autovacuum running out of memory
From
: Tom Lane
Re: Vacuum goes worse
From
: Tom Lane
Re: Vacuum goes worse
From
: Stéphane Schildknecht
Re: using a stored proc that returns a result set in a complex SQL stmt
From
: Heikki Linnakangas
using a stored proc that returns a result set in a complex SQL stmt
From
: chrisj
Re: Autovacuum running out of memory
From
: Tom Lane
Re: Autovacuum running out of memory
From
: Rodrigo Gonzalez
Re: Autovacuum running out of memory
From
: Jason Lustig
Re: Autovacuum running out of memory
From
: Mark Lewis
Re: Vacuum goes worse
From
: Tom Lane
Re: Autovacuum running out of memory
From
: Richard Huxton
Re: Autovacuum running out of memory
From
: Scott Marlowe
Re: Autovacuum running out of memory
From
: Jason Lustig
Re: Autovacuum running out of memory
From
: Scott Marlowe
Re: Autovacuum running out of memory
From
: Richard Huxton
Re: Autovacuum running out of memory
From
: Jason Lustig
Re: Autovacuum running out of memory
From
: Richard Huxton
Re: Autovacuum running out of memory
From
: Jason Lustig
Re: Autovacuum running out of memory
From
: Richard Huxton
Autovacuum running out of memory
From
: Jason Lustig
Re: Vacuum goes worse
From
: Stéphane Schildknecht
Re: Vacuum goes worse
From
: Heikki Linnakangas
Vacuum goes worse
From
: Stéphane Schildknecht
Re: How to speed up min/max(id) in 50M rows table?
From
: henk de wit
Re: How to speed up min/max(id) in 50M rows table?
From
: henk de wit
Re: How to speed up min/max(id) in 50M rows table?
From
: Tom Lane
Re: How to speed up min/max(id) in 50M rows table?
From
: henk de wit
Re: How to speed up min/max(id) in 50M rows table?
From
: Tom Lane
Re: Huge amount of memory consumed during transaction
From
: Erik Jones
Re: How to speed up min/max(id) in 50M rows table?
From
: Alan Hodgson
Re: How to speed up min/max(id) in 50M rows table?
From
: Tom Lane
Re: Huge amount of memory consumed during transaction
From
: henk de wit
Re: How to speed up min/max(id) in 50M rows table?
From
: henk de wit
Re: Huge amount of memory consumed during transaction
From
: Erik Jones
Re: How to speed up min/max(id) in 50M rows table?
From
: henk de wit
Re: Huge amount of memory consumed during transaction
From
: henk de wit
Re: How to speed up min/max(id) in 50M rows table?
From
: henk de wit
Re: How to speed up min/max(id) in 50M rows table?
From
: Kevin Grittner
How to speed up min/max(id) in 50M rows table?
From
: henk de wit
Re: Huge amount of memory consumed during transaction
From
: Tom Lane
Re: Performance problems with prepared statements
From
: Kevin Grittner
Re: Performance problems with prepared statements
From
: Theo Kramer
Re: Performance problems with prepared statements
From
: Merlin Moncure
Re: Performance problems with prepared statements
From
: Richard Huxton
Re: Performance problems with prepared statements
From
: Theo Kramer
Re: Performance problems with prepared statements
From
: Theo Kramer
Re: Performance problems with prepared statements
From
: Theo Kramer
Re: Huge amount of memory consumed during transaction
From
: Tom Lane
Re: Huge amount of memory consumed during transaction
From
: henk de wit
Re: Huge amount of memory consumed during transaction
From
: henk de wit
Re: Performance problems with prepared statements
From
: Merlin Moncure
Re: Performance problems with prepared statements
From
: Andrew - Supernews
Re: Huge amount of memory consumed during transaction
From
: Tom Lane
Re: Performance problems with prepared statements
From
: Merlin Moncure
Re: Huge amount of memory consumed during transaction
From
: Erik Jones
Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
From
: Benjamin Arai
Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
From
: Tom Lane
Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
From
: Benjamin Arai
Re: Huge amount of memory consumed during transaction
From
: Tom Lane
Re: Huge amount of memory consumed during transaction
From
: Scott Marlowe
Re: Huge amount of memory consumed during transaction
From
: Richard Huxton
Huge amount of memory consumed during transaction
From
: henk de wit
Re: Performance problems with prepared statements
From
: Theo Kramer
Re: Performance problems with prepared statements
From
: Richard Huxton
Re: building a performance test suite
From
: Dimitri Fontaine
Re: Performance problems with prepared statements
From
: Cédric Villemain
Re: Query taking too long. Problem reading explain output.
From
: Ow Mun Heng
Re: building a performance test suite
From
: Greg Smith
Re: Shared Buffer setting in postgresql.conf
From
: Scott Marlowe
Re: Shared Buffer setting in postgresql.conf
From
: Radhika S
building a performance test suite
From
: Kevin Kempter
Re: hashjoin chosen over 1000x faster plan
From
: Kevin Grittner
Re: hashjoin chosen over 1000x faster plan
From
: Tom Lane
Re: hashjoin chosen over 1000x faster plan
From
: Kevin Grittner
Re: Shared Buffer setting in postgresql.conf
From
: Scott Marlowe
Re: hashjoin chosen over 1000x faster plan
From
: Kevin Grittner
Re: hashjoin chosen over 1000x faster plan
From
: Tom Lane
Re: Shared Buffer setting in postgresql.conf
From
: Josh Trutwin
Re: hashjoin chosen over 1000x faster plan
From
: Kevin Grittner
Re: Performance problems with prepared statements
From
: Theo Kramer
Re: Performance problems with prepared statements
From
: Jonah H. Harris
Re: hashjoin chosen over 1000x faster plan
From
: Simon Riggs
Re: hashjoin chosen over 1000x faster plan
From
: Kevin Grittner
Re: Performance problems with prepared statements
From
: Theo Kramer
Re: hashjoin chosen over 1000x faster plan
From
: Simon Riggs
Re: hashjoin chosen over 1000x faster plan
From
: Simon Riggs
Re: hashjoin chosen over 1000x faster plan
From
: Kevin Grittner
Re: hashjoin chosen over 1000x faster plan
From
: Tom Lane
Re: SQL Monitoring
From
: Josh Trutwin
Re: hashjoin chosen over 1000x faster plan
From
: Simon Riggs
Re: Shared Buffer setting in postgresql.conf
From
: Scott Marlowe
Re: Performance problems with prepared statements
From
: Cédric Villemain
Re: SQL Monitoring
From
: Rodrigo De León
Performance problems with prepared statements
From
: Theo Kramer
Re: hashjoin chosen over 1000x faster plan
From
: Kevin Grittner
Re: SQL Monitoring
From
: Tomáš Vondra
Re: hashjoin chosen over 1000x faster plan
From
: Simon Riggs
Re: Shared Buffer setting in postgresql.conf
From
: Marcin Stępnicki
Re: Postgres running Very slowly
From
: Bill Moran
Shared Buffer setting in postgresql.conf
From
: Radhika S
hashjoin chosen over 1000x faster plan
From
: Kevin Grittner
Postgres running Very slowly
From
: Radhika S
Re: SQL Monitoring
From
: Gregory Stark
Re: SQL Monitoring
From
: Heikki Linnakangas
Re: SQL Monitoring
From
: Marcin Stępnicki
SQL Monitoring
From
: Campbell, Lance
Re: Apache2 PostgreSQL http authentication
From
: Magnus Hagander
Re: Apache2 PostgreSQL http authentication
From
: Tino Wildenhain
Re: postgresql on NFS.. recommended? not recommended?
From
: Josh Tolley
postgresql on NFS.. recommended? not recommended?
From
: Gábor Farkas
Re: Apache2 PostgreSQL http authentication
From
: Magnus Hagander
Re: Apache2 PostgreSQL http authentication
From
: Jeffrey Brower
Re: Apache2 PostgreSQL http authentication
From
: Jeffrey Brower
Re: Apache2 PostgreSQL http authentication
From
: D'Arcy J.M. Cain
Re: Apache2 PostgreSQL http authentication
From
: Jeffrey Brower
Re: Apache2 PostgreSQL http authentication
From
: Jeffrey Brower
Re: query plan worse after analyze
From
: Richard Broersma Jr
Re: Apache2 PostgreSQL http authentication
From
: A.M.
Apache2 PostgreSQL http authentication
From
: Jeffrey Brower
Re: query plan worse after analyze
From
: Alvaro Herrera
Re: query plan worse after analyze
From
: Jeff Frost
Re: query plan worse after analyze
From
: Tom Lane
Re: query plan worse after analyze
From
: Jeff Frost
Re: query plan worse after analyze
From
: Rodrigo De León
Re: query plan worse after analyze
From
: Stephen Frost
query plan worse after analyze
From
: Jeff Frost
Re: Problems with + 1 million record table
From
: Shane Ambler
Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
From
: Benjamin Arai
Re: Problems with + 1 million record table
From
: Joshua D. Drake
Re: Problems with + 1 million record table
From
: Arjen van der Meijden
Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
From
: Oleg Bartunov
Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
From
: Tom Lane
Re: Problems with + 1 million record table
From
: Scott Marlowe
Problems with + 1 million record table
From
: Cláudia Macedo Amorim
Slow TSearch2 performance for table with 1 million documents.
From
: Benjamin Arai
Re: Partitioning in postgres - basic question
From
: Chris
Re: Query taking too long. Problem reading explain output.
From
: Alvaro Herrera
Re: quickly getting the top N rows
From
: Ben
Re: Query taking too long. Problem reading explain output.
From
: Henrik
Re: quickly getting the top N rows
From
: Tom Lane
Re: quickly getting the top N rows
From
: Richard Huxton
Re: quickly getting the top N rows
From
: Scott Marlowe
Re: quickly getting the top N rows
From
: Ben
Re: quickly getting the top N rows
From
: Scott Marlowe
Re: quickly getting the top N rows
From
: Simon Riggs
Re: quickly getting the top N rows
From
: Ben
Re: Tuning Help - What did I do wrong?
From
: Josh Trutwin
Re: Tuning Help - What did I do wrong?
From
: Kevin Grittner
Re: quickly getting the top N rows
From
: Tom Lane
Re: quickly getting the top N rows
From
: Ben
Re: quickly getting the top N rows
From
: Andreas Kretschmer
Re: quickly getting the top N rows
From
: Bill Moran
Re: quickly getting the top N rows
From
: Mark Lewis
quickly getting the top N rows
From
: Ben
Partitioning in postgres - basic question
From
: Tore Lukashaugen
Re: Tuning Help - What did I do wrong?
From
: Scott Marlowe
Re: Tuning Help - What did I do wrong?
From
: Josh Trutwin
Re: Tuning Help - What did I do wrong?
From
: Scott Marlowe
Re: Tuning Help - What did I do wrong?
From
: Scott Marlowe
Tuning Help - What did I do wrong?
From
: Josh Trutwin
Re: Query taking too long. Problem reading explain output.
From
: Alvaro Herrera
Re: can't shrink relation
From
: Guillaume Cottenceau
Re: can't shrink relation
From
: Richard Huxton
Re: Query taking too long. Problem reading explain output.
From
: Henrik
can't shrink relation
From
: Sabin Coanda
Re: can't shrink relation
From
: Sabin Coanda
Re: Query taking too long. Problem reading explain output.
From
: Tom Lane
Re: Query taking too long. Problem reading explain output.
From
: Michael Fuhr
Query taking too long. Problem reading explain output.
From
: Henrik
Re: Newbie question about degraded performance on delete statement. (SOLVED)
From
: Giulio Cesare Solaroli
Re: Newbie question about degraded performance on delete statement.
From
: Giulio Cesare Solaroli
Re: Difference between Vacuum and Vacuum full
From
: Radhika S
Re: Difference between Vacuum and Vacuum full
From
: D'Arcy J.M. Cain
Re: Difference between Vacuum and Vacuum full
From
: Rodrigo De León
Re: Difference between Vacuum and Vacuum full
From
: Scott Marlowe
Difference between Vacuum and Vacuum full
From
: Radhika S
Re: Newbie question about degraded performance on delete statement.
From
: Greg Williamson
Re: performance of like queries
From
: Chris Browne
Re: Linux mis-reporting memory
From
: Decibel!
Re: Newbie question about degraded performance on delete statement.
From
: Dan Langille
Newbie question about degraded performance on delete statement.
From
: Giulio Cesare Solaroli
Re: performance of like queries
From
: Marcin Stępnicki
Re: performance of like queries
From
: Joshua D. Drake
performance of like queries
From
: Kevin Kempter
Re: Linux mis-reporting memory
From
: Adam Tauno Williams
Re: Linux mis-reporting memory
From
: Scott Marlowe
Re: Linux mis-reporting memory
From
: Decibel!
Re: sequence query performance issues
From
: Peter Koczan
Re: Non-blocking vacuum full
From
: Heikki Linnakangas
Re: Non-blocking vacuum full
From
: Ron Mayer
Re: OOM Errors as a result of table inheritance and a bad plan(?)
From
: Tom Lane
Re: Non-blocking vacuum full
From
: Heikki Linnakangas
Non-blocking vacuum full
From
: Peter Schuller
OOM Errors as a result of table inheritance and a bad plan(?)
From
: Arctic Toucan
Re: sequence query performance issues
From
: Peter Koczan
Re: Postgres 7.4.2 hanging when vacuum full is run
From
: Scott Marlowe
Re: Postgres 7.4.2 hanging when vacuum full is run
From
: Vivek Khera
Re: sequence query performance issues
From
: Richard Huxton
Postgres 7.4.2 hanging when vacuum full is run
From
: Radhika S
Re: sequence query performance issues
From
: Tom Lane
Re: Tuning for warm standby
From
: Merlin Moncure
Re: Searching for the cause of a bad plan
From
: Csaba Nagy
Re: Searching for the cause of a bad plan
From
: Csaba Nagy
Re: sequence query performance issues
From
: Richard Huxton
sequence query performance issues
From
: Peter Koczan
Re: Searching for the cause of a bad plan
From
: Ron Mayer
Tuning for warm standby
From
: Kevin Kempter
Re: Searching for the cause of a bad plan
From
: Simon Riggs
Re: Searching for the cause of a bad plan
From
: Csaba Nagy
Re: Searching for the cause of a bad plan
From
: Tom Lane
Re: Difference in query plan when using = or > in where clause
From
: Heikki Linnakangas
Re: Searching for the cause of a bad plan
From
: Csaba Nagy
Re: REPOST: Nested loops row estimates always too high
From
: Ow Mun Heng
Difference in query plan when using = or > in where clause
From
: Radhika S
Re: Incorrect row estimates in plan?
From
: pgdba
Re: Incorrect row estimates in plan?
From
: Tom Lane
Re: Incorrect row estimates in plan?
From
: pgdba
Re: Searching for the cause of a bad plan
From
: Tom Lane
Re: Searching for the cause of a bad plan
From
: Csaba Nagy
Re: Incorrect row estimates in plan?
From
: Tom Lane
Incorrect row estimates in plan?
From
: pgdba
Re: Effects of cascading references in foreign keys
From
: Bruce Momjian
Re: REPOST: Nested loops row estimates always too high
From
: Tom Lane
Re: REPOST: Nested loops row estimates always too high
From
: Ow Mun Heng
Re: query io stats and finding a slow query
From
: Bryan Murphy
Re: query io stats and finding a slow query
From
: Kamen Stanev
Re: Attempting to disable count triggers on cleanup
From
: Dave Cramer
Re: Attempting to disable count triggers on cleanup
From
: hubert depesz lubaczewski
Attempting to disable count triggers on cleanup
From
: Dave Cramer
Re: REPOST: Nested loops row estimates always too high
From
: Steinar H. Gunderson
Re: REPOST: Nested loops row estimates always too high
From
: Ow Mun Heng
Re: REPOST: Nested loops row estimates always too high
From
: Carlo Stonebanks
Re: REPOST: Nested loops row estimates always too high
From
: Ow Mun Heng
Re: Acceptable level of over-estimation?
From
: Gregory Stark
Acceptable level of over-estimation?
From
: Carlo Stonebanks
Re: REPOST: Nested loops row estimates always too high
From
: Carlo Stonebanks
Re: Searching for the cause of a bad plan
From
: Simon Riggs
Re: TEXT or LONGTEXT?
From
: Niklas Johansson
Re: select count(*) performance (vacuum did not help)
From
: Dave Dutcher
Re: select count(*) performance (vacuum did not help)
From
: Csaba Nagy
Re: TEXT or LONGTEXT?
From
: Alexander Staubo
Re: select count(*) performance (vacuum did not help)
From
: Bill Moran
TEXT or LONGTEXT?
From
: Fabiola Fernández
Re: select count(*) performance (vacuum did not help)
From
: Gábor Farkas
Re: select count(*) performance (vacuum did not help)
From
: Heikki Linnakangas
Re: select count(*) performance (vacuum did not help)
From
: Gábor Farkas
Re: select count(*) performance (vacuum did not help)
From
: Heikki Linnakangas
Re: select count(*) performance (vacuum did not help)
From
: Pavan Deolasee
Re: Low CPU Usage
From
: brauagustin-susc
select count(*) performance (vacuum did not help)
From
: Gábor Farkas
Re: Searching for the cause of a bad plan
From
: Csaba Nagy
Re: Low CPU Usage
From
: brauagustin-susc
Re: Searching for the cause of a bad plan
From
: Simon Riggs
[OT] Re: [Again] Postgres performance problem
From
: Ow Mun Heng
Re: REPOST: Nested loops row estimates always too high
From
: Ow Mun Heng
Re: Possible explanations for catastrophic performance deterioration?
From
: Gregory Stark
Re: Possible explanations for catastrophic performance deterioration?
From
: Jonah H. Harris
Re: Possible explanations for catastrophic performance deterioration?
From
: Carlos Moreno
Re: Possible explanations for catastrophic performance deterioration?
From
: Alvaro Herrera
Re: Possible explanations for catastrophic performance deterioration?
From
: Carlos Moreno
Re: Possible explanations for catastrophic performace deterioration?
From
: Jonah H. Harris
Re: Possible explanations for catastrophic performace deterioration?
From
: Carlos Moreno
Re: Possible explanations for catastrophic performace deterioration?
From
: Alvaro Herrera
Re: Possible explanations for catastrophic performace deterioration?
From
: Carlos Moreno
Re: Possible explanations for catastrophic performace deterioration?
From
: Tom Lane
zero value in statistics collector's result
From
: Yinan Li
Re: Possible explanations for catastrophic performace deterioration?
From
: Jonah H. Harris
Possible explanations for catastrophic performace deterioration?
From
: Carlos Moreno
Re: Query planner unaware of possibly best plan
From
: Denes Daniel
Re: Low CPU Usage
From
: Greg Smith
Re: Query planner unaware of possibly best plan
From
: Tom Lane
Re: Query planner unaware of possibly best plan
From
: Denes Daniel
Re: Searching for the cause of a bad plan
From
: Tom Lane
Re: Low CPU Usage
From
: brauagustin-susc
Re: Low CPU Usage
From
: Craig James
Re: Low CPU Usage
From
: Kevin Grittner
Re: Low CPU Usage
From
: Dave Dutcher
Re: Low CPU Usage
From
: Luiz K. Matsumura
Re: Query planner unaware of possibly best plan
From
: Denes Daniel
Re: Query planner unaware of possibly best plan
From
: Alvaro Herrera
Re: Low CPU Usage
From
: brauagustin-susc
Re: Query planner unaware of possibly best plan
From
: Denes Daniel
Re: Linux mis-reporting memory
From
: Greg Smith
Re: Low CPU Usage
From
: Bill Moran
Re: Low CPU Usage
From
: brauagustin-susc
Re: Searching for the cause of a bad plan
From
: Simon Riggs
Re: Low CPU Usage
From
: Bill Moran
Re: Low CPU Usage
From
: brauagustin-susc
Re: Searching for the cause of a bad plan
From
: Tom Lane
Re: Low CPU Usage
From
: brauagustin-susc
Re: Low CPU Usage
From
: Kevin Grittner
Re: Query planner unaware of possibly best plan
From
: Simon Riggs
Re: Searching for the cause of a bad plan
From
: Simon Riggs
Re: Low CPU Usage
From
: brauagustin-susc
Re: Searching for the cause of a bad plan
From
: Simon Riggs
Re: query io stats and finding a slow query
From
: Kevin Grittner
Re: Searching for the cause of a bad plan
From
: Tom Lane
Re: Searching for the cause of a bad plan
From
: Csaba Nagy
Query planner unaware of possibly best plan
From
: Denes Daniel
Re: Searching for the cause of a bad plan
From
: Csaba Nagy
Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
From
: Dave Dutcher
Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
From
: Jeff Harris
Re: Searching for the cause of a bad plan
From
: Simon Riggs
Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
From
: Bill Moran
Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
From
: smiley2211
Re: Searching for the cause of a bad plan
From
: Csaba Nagy
Re: Searching for the cause of a bad plan
From
: Simon Riggs
Re: Linux mis-reporting memory
From
: Csaba Nagy
Re: Searching for the cause of a bad plan
From
: Csaba Nagy
Re: Linux mis-reporting memory
From
: Simon Riggs
Re: Searching for the cause of a bad plan
From
: Simon Riggs
Re: Linux mis-reporting memory
From
: Heikki Linnakangas
Re: Linux mis-reporting memory
From
: Csaba Nagy
Searching for the cause of a bad plan
From
: Csaba Nagy
Re: Linux mis-reporting memory
From
: Gregory Stark
Re: Linux mis-reporting memory
From
: Dimitri Fontaine
Re: Linux mis-reporting memory
From
: Csaba Nagy
Re: Linux mis-reporting memory
From
: Gregory Stark
Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
From
: db
Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
From
: smiley2211
Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
From
: Scott Marlowe
Re: Linux mis-reporting memory
From
: Adam Tauno Williams
Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
From
: smiley2211
Re: Linux mis-reporting memory
From
: Tom Lane
Linux mis-reporting memory
From
: Decibel!
query io stats and finding a slow query
From
: Kamen Stanev
[Index of Archives]
[Postgresql General]
[Postgresql PHP]
[PHP Home]
[PHP on Windows]
[Yosemite]
