Mailing lists [pgsql-performance]

1 September 2012

• 03:44   Re: JDBC 5 million function insert returning Single Transaction Lock Access Exclusive Problem Craig Ringer
• 05:12   Re: NOTIFY performance Jeff Janes
• 19:25   Re: Bad query plan when the wrong data type is used Bruce Momjian

3 September 2012

• 00:39   Re: [HACKERS] pg_dump and thousands of schemas Jeff Janes
• 07:37   Re: [HACKERS] pg_dump and thousands of schemas Robert Haas
• 11:35   Re: Execution from java - slow Jayadevan M
• 14:03   Inserts in 'big' table slowing down the database Stefan Keller
• 14:21   Re: Inserts in 'big' table slowing down the database Ivan Voras
• 14:22   Re: exponential performance decrease in ISD transaction John Nash
• 20:27   Re: exponential performance decrease in ISD transaction Jeff Janes

6 September 2012

• 00:48   query performance, where goes time? Anibal David Acosta
• 04:26   Re: query performance, where goes time? Craig Ringer
• 06:20   Re: [repost] Help me develop new commit_delay advice Greg Smith
• 06:55   Re: exponential performance decrease in ISD transaction Greg Smith
• 09:56   HELP!!!-----Need to Sql commands to monitoring Postgresql charles_xie
• 09:56   Re: JDBC 5 million function insert returning Single Transaction Lock Access Exclusive Problem Eileen
• 10:44   Re: HELP!!!-----Need to Sql commands to monitoring Postgresql Daniel Farina
• 22:45   Re: HELP!!!-----Need to Sql commands to monitoring Postgresql Josh Berkus
• 22:50   Re: HELP!!!-----Need to Sql commands to monitoring Postgresql Steven Crandell

7 September 2012

• 08:11   libpq or postgresql performance Aryan Ariel Rodriguez Chalas
• 08:11   Re: HELP!!!-----Need to Sql commands to monitoring Postgresql charles_xie
• 08:35   Re: libpq or postgresql performance Andreas Kretschmer
• 08:46   Re: HELP!!!-----Need to Sql commands to monitoring Postgresql Daniel Farina
• 09:45   Re: libpq or postgresql performance Albe Laurenz
• 09:52   Re: libpq or postgresql performance Ireneusz Pluta
• 13:56   Re: exponential performance decrease in ISD transaction John Nash
• 13:57   Re: exponential performance decrease in ISD transaction John Nash
• 20:25   Re: libpq or postgresql performance Ireneusz Pluta

10 September 2012

• 12:01   Re: libpq or postgresql performance Ireneusz Pluta
• 15:39   : PostgreSQL Index behavior Venkat Balaji
• 17:27   Planner selects different execution plans depending on limit bill_martin@freenet.de
• 17:40   force defaults Willy-Bas Loos
• 18:36   Re: : PostgreSQL Index behavior Jeff Janes
• 21:18   Re: Planner selects different execution plans depending on limit Jesper Krogh

11 September 2012

• 00:06   Re: Slow Performance on a XEON E5504 Marcos Ortiz
• 10:21   Re: Planner selects different execution plans depending on limit Bill Martin
• 16:20   add column with default value is very slow AI Rumman
• 16:42   Re: add column with default value is very slow Albe Laurenz
• 16:44   Re: add column with default value is very slow hubert depesz lubaczewski
• 16:55   Re: add column with default value is very slow AI Rumman
• 16:59   Re: add column with default value is very slow hubert depesz lubaczewski
• 17:04   Re: add column with default value is very slow AI Rumman
• 17:05   Re: add column with default value is very slow hubert depesz lubaczewski
• 17:07   Re: add column with default value is very slow Andrew Dunstan
• 20:19   Re: Planner selects different execution plans depending on limit Tom Lane

12 September 2012

• 09:58   Re: : PostgreSQL Index behavior Venkat Balaji
• 17:13   Re: : PostgreSQL Index behavior Scott Marlowe
• 19:00   Guide to Posting Slow Query Questions Jeff Janes

13 September 2012

• 12:05   Re: Planner selects different execution plans depending on limit Bill Martin
• 12:22   Re: : PostgreSQL Index behavior Venkat Balaji
• 12:39   Re: : PostgreSQL Index behavior Tomas Vondra
• 17:04   Re: Planner selects different execution plans depending on limit Tom Lane
• 17:42   Re: Planner selects different execution plans depending on limit Bill Martin
• 17:48   Re: Planner selects different execution plans depending on limit Jesper Krogh
• 18:00   Re: Planner selects different execution plans depending on limit Tom Lane
• 20:19   Re: Planner selects different execution plans depending on limit Bill Martin
• 20:33   Re: Planner selects different execution plans depending on limit Tom Lane
• 21:11   AppScale backend datastore (NoSQL again kind of) Ross Reedstrom
• 21:25    Feridun türk
• 21:30   Re: AppScale backend datastore (NoSQL again kind of) Marcos Ortiz
• 22:00   Re: Linux machine aggressively clearing cache Ross Reedstrom

14 September 2012

• 01:15   Re: AppScale backend datastore (NoSQL again kind of) Mark Kirkwood
• 10:40   20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets Nikolay Ulyanitsky
• 11:14   Re: Guide to Posting Slow Query Questions Ants Aasma
• 11:46   Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets Daniel Farina
• 17:57   Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets Marcos Ortiz
• 18:04   Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets Nikolay Ulyanitsky
• 18:29   Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets Craig James
• 18:35   Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets Nikolay Ulyanitsky
• 18:56   Are there known performance issues with defining all Foreign Keys as deferrable initially immediate McKinzie, Alan (Alan)
• 23:11   Setting autovacuum_vacuum_scale_factor to 0 a good idea ? Sébastien Lorion
• 23:20   wal_sync_method on FreeBSD 9.0 - ZFS Sébastien Lorion

15 September 2012

• 00:49   Re: Setting autovacuum_vacuum_scale_factor to 0 a good idea ? Josh Berkus
• 05:35   Re: Setting autovacuum_vacuum_scale_factor to 0 a good idea ? Sébastien Lorion
• 19:16   Remote access to Postgresql slow Manoj Agarwal

16 September 2012

• 00:17   Re: Remote access to Postgresql slow Andrew Barnham
• 00:20   Re: Remote access to Postgresql slow Scott Marlowe
• 16:45   Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate Craig Ringer
• 17:12   Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate Craig Ringer
• 18:37   Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate Tom Lane

17 September 2012

• 05:59   Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate Craig Ringer
• 16:38   Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate McKinzie, Alan (Alan)

18 September 2012

• 10:28   Re: Planner selects different execution plans depending on limit Bill Martin
• 10:44   Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets Andrea Suisani
• 16:54   Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets Merlin Moncure
• 17:25   Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets Andrea Suisani

20 September 2012

• 15:06   problems with large objects dump Sergio Gabriel Rodriguez
• 17:36   Re: problems with large objects dump Tom Lane
• 19:29   Re: problems with large objects dump Sergio Gabriel Rodriguez
• 19:33   Re: problems with large objects dump Tom Lane

22 September 2012

• 05:31   PostgreSQL performance on 64 bit as compared to 32 bit Umesh Kirdat
• 05:31   Re: wal_sync_method on FreeBSD 9.0 - ZFS Ivan Voras
• 05:32   Cost of opening and closing an empty transaction Jon Leighton
• 05:32   Query Planner Optimization? Brandon
• 05:36   Newbie performance problem - semop taking most of time ? mal.oracledba
• 05:43   Re: PostgreSQL performance on 64 bit as compared to 32 bit Claudio Freire
• 06:08   Re: Cost of opening and closing an empty transaction Claudio Freire
• 08:51   Re: Newbie performance problem - semop taking most of time ? Daniel Farina
• 17:02   Re: wal_sync_method on FreeBSD 9.0 - ZFS Sébastien Lorion

23 September 2012

• 22:42   Re: Newbie performance problem - semop taking most of time ? mal.oracledba
• 23:36   Re: Newbie performance problem - semop taking most of time ? Tom Lane

24 September 2012

• 09:41   Memory issues Shiran Kleiderman
• 12:49   Re: Cost of opening and closing an empty transaction Albe Laurenz
• 13:33   Postgres becoming slow, only full vacuum fixes it Kiriakos Tsourapas
• 14:55   Re: Postgres becoming slow, only full vacuum fixes it Kiriakos Tsourapas
• 15:21   Re: Postgres becoming slow, only full vacuum fixes it Julien Cigar
• 15:35   Re: Postgres becoming slow, only full vacuum fixes it Andres Freund
• 15:54   Re: Postgres becoming slow, only full vacuum fixes it Julien Cigar
• 16:34   Re: Postgres becoming slow, only full vacuum fixes it Andres Freund
• 16:51   Re: Postgres becoming slow, only full vacuum fixes it Kiriakos Tsourapas
• 17:14   Re: Postgres becoming slow, only full vacuum fixes it Julien Cigar
• 18:20   Re: Postgres becoming slow, only full vacuum fixes it MirrorX

25 September 2012

• 00:43   Re: Postgres becoming slow, only full vacuum fixes it Ondrej Ivanič
• 02:08   Re: Postgres becoming slow, only full vacuum fixes it Mark Kirkwood
• 08:49   Spurious failure to obtain row lock possible in PG 9.1? henk de wit
• 13:48   Re: Spurious failure to obtain row lock possible in PG 9.1? Albe Laurenz
• 14:01   Re: Postgres becoming slow, only full vacuum fixes it Kiriakos Tsourapas
• 14:08   Re: Postgres becoming slow, only full vacuum fixes it Kiriakos Tsourapas
• 14:10   Re: Postgres becoming slow, only full vacuum fixes it Kiriakos Tsourapas
• 15:41   Re: Postgres becoming slow, only full vacuum fixes it Kevin Grittner

26 September 2012

• 02:14   Re: Postgres becoming slow, only full vacuum fixes it Ondrej Ivanič
• 12:41   Re: Postgres becoming slow, only full vacuum fixes it Kiriakos Tsourapas
• 15:27   Same query doing slow then quick FFW_Rude
• 15:58   Re: Postgres becoming slow, only full vacuum fixes it Kevin Grittner
• 16:03   Re: Same query doing slow then quick FFW_Rude
• 16:21   Re: Same query doing slow then quick Julien Cigar
• 16:36   Re: Same query doing slow then quick FFW_Rude
• 16:49   Re: Same query doing slow then quick Julien Cigar
• 16:50   Re: Postgres becoming slow, only full vacuum fixes it Kiriakos Tsourapas
• 17:14   Re: Same query doing slow then quick FFW_Rude
• 17:17   Re: Same query doing slow then quick Julien Cigar
• 17:19   Re: Same query doing slow then quick FFW_Rude
• 17:41   Re: Same query doing slow then quick FFW_Rude
• 17:52   Re: Same query doing slow then quick Julien Cigar
• 18:18   Re: Same query doing slow then quick FFW_Rude
• 18:33   Re: Same query doing slow then quick Nikolay Ulyanitsky
• 18:39   Re: Same query doing slow then quick FFW_Rude
• 18:52   Re: Same query doing slow then quick Nikolay Ulyanitsky
• 19:05   Re: Same query doing slow then quick Undertaker Rude
• 19:09   Re: Same query doing slow then quick FFW_Rude
• 19:30   Re: Same query doing slow then quick Nikolay Ulyanitsky
• 21:38   Inaccurate Explain Cost Robert Sosinski
• 23:03   Re: Inaccurate Explain Cost Shaun Thomas
• 23:11   Re: Guide to Posting Slow Query Questions Jeff Janes
• 23:21   Re: Inaccurate Explain Cost hubert depesz lubaczewski
• 23:55   Re: [GENERAL] Memory issues Scott Marlowe

27 September 2012

• 00:00   Re: [GENERAL] Memory issues Shiran Kleiderman
• 00:11   Re: [GENERAL] Memory issues Scott Marlowe
• 00:36   Re: [GENERAL] Memory issues Shiran Kleiderman
• 01:01   Re: [GENERAL] Memory issues Shiran Kleiderman
• 01:42   Re: Inaccurate Explain Cost Samuel Gendler
• 03:04   Re: [GENERAL] Inaccurate Explain Cost Jeff Janes
• 11:33   Re: Same query doing slow then quick Undertaker Rude
• 12:01   Re: Same query doing slow then quick Undertaker Rude
• 22:11   hardware advice M. D.
• 22:22   Re: hardware advice Claudio Freire
• 22:37   Re: hardware advice Craig James
• 22:40   Re: hardware advice M. D.
• 22:40   Re: hardware advice David Boreham
• 22:47   Re: hardware advice David Boreham
• 22:56   Re: hardware advice M. D.
• 23:13   Re: hardware advice David Boreham
• 23:31   Re: hardware advice Alan Hodgson
• 23:44   Re: hardware advice Scott Marlowe
• 23:46   Re: hardware advice M. D.
• 23:47   Re: hardware advice Shaun Thomas
• 23:50   Re: hardware advice Shaun Thomas
• 23:55   Re: hardware advice Scott Marlowe
• 23:56   Re: hardware advice Scott Marlowe

28 September 2012

• 00:01   Re: hardware advice Shaun Thomas
• 00:05   Re: hardware advice David Boreham
• 00:08   Re: hardware advice David Boreham
• 00:08   Re: hardware advice Evgeny Shishkin
• 00:16   Re: hardware advice Claudio Freire
• 00:18   Re: hardware advice Alan Hodgson
• 00:20   Re: hardware advice Shaun Thomas
• 00:22   Re: hardware advice M. D.
• 00:29   Re: hardware advice David Boreham
• 00:29   Re: hardware advice Evgeny Shishkin
• 00:32   Re: hardware advice Scott Marlowe
• 00:36   Re: hardware advice Scott Marlowe
• 00:39   Re: hardware advice Scott Marlowe
• 00:40   Re: hardware advice Evgeny Shishkin
• 00:44   Re: hardware advice Shaun Thomas
• 02:52   Re: hardware advice Scott Marlowe
• 02:56   Re: hardware advice Scott Marlowe
• 02:57   Re: hardware advice Scott Marlowe
• 09:52   Re: Postgres becoming slow, only full vacuum fixes it Kiriakos Tsourapas
• 13:38   Re: hardware advice Jeremy Harris
• 13:43   exponentia​l performanc​e decrease, problem with version postgres + RHEL? John Nash
• 13:47   Re: [PERFORM] exponentia​l performanc​e decrease, problem with version postgres + RHEL? Nikolay Ulyanitsky
• 13:58   RE: [PERFORM] exponentia​l performanc​e decrease, problem with version postgres + RHEL? Albe Laurenz
• 13:58   Re: [PERFORM] Re: [PERFORM] exponentia​l performanc​e decrease, problem with version postgres + RHEL? John Nash
• 16:52   "Select * " on 12-18M row table from remote machine thru JDBC - Performance nose-dives after 10M-ish records antthelimey
• 18:10   Re: "Select * " on 12-18M row table from remote machine thru JDBC - Performance nose-dives after 10M-ish records Deron
• 18:38   Re: hardware advice ktm@rice.edu
• 18:46   Re: hardware advice Craig James
• 18:57   Re: hardware advice David Boreham
• 20:34   Re: hardware advice M. D.
• 22:23   Possible Performance Regression with Transitive Comparisons vs. Constants Shaun Thomas
• 23:35   Re: Possible Performance Regression with Transitive Comparisons vs. Constants Tom Lane

29 September 2012

• 00:04   Query plan, nested EXISTS Matt Daw
• 00:37   Re: Possible Performance Regression with Transitive Comparisons vs. Constants Shaun Thomas
• 00:44   Re: Query plan, nested EXISTS Tom Lane
• 00:47   Re: Query plan, nested EXISTS Matt Daw
• 01:26   Re: Possible Performance Regression with Transitive Comparisons vs. Constants Tom Lane
• 01:56   Re: Query plan, nested EXISTS Matt Daw
• 02:12   NestedLoops over BitmapScan question Виктор Егоров
• 02:48   Re: hardware advice Scott Marlowe
• 04:43   Re: Postgres becoming slow, only full vacuum fixes it Thomas Kellerer
• 04:43   wrong join result set estimate Evgeny Shishkin
• 04:48   Re: [GENERAL] Inaccurate Explain Cost Matthias
• 09:59   Re: Postgres becoming slow, only full vacuum fixes it Scott Marlowe