Mailing lists [pgsql-performance]

1 July 2011

• 13:54   Re: is parallel union all possible over dblink? Svetlin Manavski
• 14:43   Infinite Cache Anthony Presley
• 15:54   Re: Infinite Cache Greg Smith
• 22:38   Re: Infinite Cache Jim Nasby
• 22:47   Re: near identical queries have vastly different plans Tom Lane

2 July 2011

• 00:51   Re: near identical queries have vastly different plans Samuel Gendler
• 08:20   Re: Infinite Cache Dave Page

3 July 2011

• 04:14   How can retrieve total query run-time with out using explain Radhya sahal
• 06:09   Re: How can retrieve total query run-time with out using explain Craig Ringer
• 11:21   Re: Infinite Cache Magnus Hagander
• 18:18   Re: Infinite Cache Greg Smith

5 July 2011

• 10:15   Re: bitmask index Marcus Engene
• 13:35   Re: Infinite Cache Shaun Thomas
• 14:42   Postgres bulkload without transaction logs shouvik basu
• 17:41   Re: Postgres bulkload without transaction logs Greg Smith
• 17:43   Re: bitmask index Greg Smith

6 July 2011

• 00:27   Slow query when using ORDER BY *and* LIMIT Jonathan
• 07:09   Query in 9.0.2 not using index in 9.0.0 works fine Matthias Howell
• 07:09   GROUP BY with reasonable timings in PLAN but unreasonable execution time Clem Dickey
• 07:42   Re: Query in 9.0.2 not using index in 9.0.0 works fine Samuel Gendler
• 13:30   Re: 100% CPU Utilization when we run queries. bakkiya
• 13:47   Re: 100% CPU Utilization when we run queries. Kevin Grittner
• 15:39   Re: Query in 9.0.2 not using index in 9.0.0 works fine Matthias Howell
• 19:04   Re: 100% CPU Utilization when we run queries. Tomas Vondra
• 20:01   Re: Query in 9.0.2 not using index in 9.0.0 works fine Samuel Gendler
• 21:06   Re: 100% CPU Utilization when we run queries. Scott Marlowe
• 23:36   Re: 100% CPU Utilization when we run queries. Craig Ringer

7 July 2011

• 07:19   Re: GROUP BY with reasonable timings in PLAN but unreasonable execution time Clem Dickey
• 09:45   Re: 100% CPU Utilization when we run queries. Robert Klemme
• 12:49   Re: 100% CPU Utilization when we run queries. bakkiya
• 15:26   DELETE taking too much memory vincent dephily
• 15:26   very large record sizes and ressource usage jtkells@verizon.net
• 20:26   Re: [GENERAL] DELETE taking too much memory Guillaume Lelarge
• 20:30   "VACUUM FULL ANALYZE" vs. Autovacuum Contention D C
• 21:21   Re: "VACUUM FULL ANALYZE" vs. Autovacuum Contention Scott Marlowe
• 21:31   Re: "VACUUM FULL ANALYZE" vs. Autovacuum Contention Greg Smith

8 July 2011

• 09:05   Re: [GENERAL] DELETE taking too much memory Dean Rasheed
• 10:49   Re: [GENERAL] DELETE taking too much memory Dean Rasheed
• 11:09   Re: [GENERAL] DELETE taking too much memory Claudio Freire
• 11:23   execution time for first INSERT Sergio Mayoral
• 13:34   Re: Infinite Cache Heikki Linnakangas
• 13:37   Re: [GENERAL] DELETE taking too much memory Jose Ildefonso Camargo Tolosa
• 13:42   Re: Infinite Cache Magnus Hagander
• 16:47   Re: "VACUUM FULL ANALYZE" vs. Autovacuum Contention D C
• 17:12   Re: "VACUUM FULL ANALYZE" vs. Autovacuum Contention Greg Smith
• 20:20   Just a note about column equivalence disarming the planner Shaun Thomas
• 21:36   issue with query optimizer when joining two partitioned tables Anish Kejariwal
• 22:24   Re: Slow query when using ORDER BY *and* LIMIT Jonathan

9 July 2011

• 00:40   Re: execution time for first INSERT Jeff Davis
• 03:40   Re: Slow query when using ORDER BY *and* LIMIT Pavel Stehule
• 03:50   Re: Slow query when using ORDER BY *and* LIMIT Pavel Stehule
• 07:49   Memory usage of auto-vacuum Gael Le Mignot
• 07:54   Re: issue with query optimizer when joining two partitioned tables Heikki Linnakangas
• 08:32   Re: Memory usage of auto-vacuum Craig Ringer
• 08:33   Re: Memory usage of auto-vacuum Guillaume Lelarge
• 08:39   Re: Memory usage of auto-vacuum Gael Le Mignot
• 08:43   Re: Memory usage of auto-vacuum Gael Le Mignot
• 08:53   Re: Memory usage of auto-vacuum Guillaume Lelarge
• 09:00   Re: Memory usage of auto-vacuum Gael Le Mignot
• 09:06   Re: Memory usage of auto-vacuum Guillaume Lelarge
• 09:27   Re: Memory usage of auto-vacuum Gael Le Mignot
• 12:15   Re: Memory usage of auto-vacuum Craig Ringer
• 16:23   Re: Memory usage of auto-vacuum Tom Lane
• 17:44   Re: issue with query optimizer when joining two partitioned tables Tom Lane

10 July 2011

• 07:37   INSERT query times sergio mayoral
• 07:37   Re: DELETE taking too much memory French, Martin
• 07:37   "VACUUM FULL ANALYZE" vs. Autovacuum Contention D C
• 07:37   Very large record sizes and resource usage jtkells@verizon.net
• 07:37   Re: [GENERAL] DELETE taking too much memory Vincent de Phily
• 07:37   Re: DELETE taking too much memory Vincent de Phily
• 07:37   Re: DELETE taking too much memory French, Martin
• 07:37   Re: [GENERAL] DELETE taking too much memory Vincent de Phily
• 07:37   Re: GROUP BY with reasonable timings in PLAN but unreasonable execution time Clem Dickey
• 07:37   Re: DELETE taking too much memory Vincent de Phily
• 07:38   UPDATEDs slowing SELECTs in a fully cached database lars
• 08:12   Re: INSERT query times Pavel Stehule
• 15:34   Re: issue with query optimizer when joining two partitioned tables Anish Kejariwal
• 15:49   Re: Memory usage of auto-vacuum Gael Le Mignot
• 16:06   Re: issue with query optimizer when joining two partitioned tables Jeremy Harris
• 16:41   query total time im milliseconds Radhya sahal
• 16:43   Re: INSERT query times Tom Lane
• 16:44   query total time im milliseconds Radhya sahal
• 17:52   Re: query total time im milliseconds Samuel Gendler
• 18:13   query total time im milliseconds Radhya sahal
• 18:13   query total time im milliseconds Radhya sahal
• 18:26   Fw: query total time im milliseconds Radhya sahal
• 20:34   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 21:16   Statistics and Multi-Column indexes lars
• 21:31   Re: Statistics and Multi-Column indexes Samuel Gendler
• 22:21   Re: query total time im milliseconds Craig Ringer
• 22:54   Re: Fw: query total time im milliseconds Craig Ringer
• 23:11   Re: UPDATEDs slowing SELECTs in a fully cached database Craig Ringer

11 July 2011

• 04:47   Re: UPDATEDs slowing SELECTs in a fully cached database lars hofhansl
• 13:14   Re: UPDATEDs slowing SELECTs in a fully cached database ktm@rice.edu
• 15:27   Re: UPDATEDs slowing SELECTs in a fully cached database Robert Klemme
• 16:15   Re: UPDATEDs slowing SELECTs in a fully cached database ktm@rice.edu
• 17:34   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 18:33   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 19:16   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 20:32   Re: Statistics and Multi-Column indexes Kevin Grittner
• 21:43   Re: UPDATEDs slowing SELECTs in a fully cached database Merlin Moncure
• 21:55   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 22:11   Re: UPDATEDs slowing SELECTs in a fully cached database Merlin Moncure
• 23:03   Re: UPDATEDs slowing SELECTs in a fully cached database lars

12 July 2011

• 00:09   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 04:43   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 13:23   Re: UPDATEDs slowing SELECTs in a fully cached database Ivan Voras
• 14:18   Re: UPDATEDs slowing SELECTs in a fully cached database Merlin Moncure
• 14:36   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 14:43   Re: UPDATEDs slowing SELECTs in a fully cached database Ivan Voras
• 15:13   Re: UPDATEDs slowing SELECTs in a fully cached database Ivan Voras
• 15:44   Re: Memory usage of auto-vacuum Gael Le Mignot
• 16:23   Re: UPDATEDs slowing SELECTs in a fully cached database Merlin Moncure
• 18:18   Planner choosing NestedLoop, although it is slower... Mario Splivalo
• 19:02   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 19:08   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 19:26   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 20:04   Re: Planner choosing NestedLoop, although it is slower... Tom Lane
• 20:05   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 20:51   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 20:58   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 21:38   Re: UPDATEDs slowing SELECTs in a fully cached database Merlin Moncure
• 21:51   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 22:06   Re: Planner choosing NestedLoop, although it is slower... Mario Splivalo
• 22:36   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 22:39   Re: Planner choosing NestedLoop, although it is slower... Tom Lane
• 23:15   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 23:57   Re: Planner choosing NestedLoop, although it is slower... Mario Splivalo

13 July 2011

• 00:40   Re: UPDATEDs slowing SELECTs in a fully cached database Jeff Janes
• 00:53   Re: Planner choosing NestedLoop, although it is slower... Mario Splivalo
• 01:16   Re: UPDATEDs slowing SELECTs in a fully cached database Tom Lane
• 02:04   Re: Planner choosing NestedLoop, although it is slower... Mario Splivalo
• 04:01   Re: UPDATEDs slowing SELECTs in a fully cached database Lars
• 14:46   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 14:53   Re: UPDATEDs slowing SELECTs in a fully cached database Merlin Moncure
• 15:17   Re: UPDATEDs slowing SELECTs in a fully cached database Tom Lane
• 18:12   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 18:23   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 18:42   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 19:01   Re: UPDATEDs slowing SELECTs in a fully cached database Merlin Moncure
• 21:57   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 22:21   Re: UPDATEDs slowing SELECTs in a fully cached database Tom Lane
• 22:41   Re: UPDATEDs slowing SELECTs in a fully cached database lars

14 July 2011

• 07:25   Trigger or Function alan
• 07:25   Re: Planner choosing NestedLoop, although it is slower... Clem Dickey
• 11:09   Re: Trigger or Function Robert Klemme
• 14:31   Re: UPDATEDs slowing SELECTs in a fully cached database Kevin Grittner
• 15:06   Re: UPDATEDs slowing SELECTs in a fully cached database Robert Klemme
• 16:01   Re: UPDATEDs slowing SELECTs in a fully cached database Tom Lane
• 21:45   Re: UPDATEDs slowing SELECTs in a fully cached database Jeff Janes
• 23:03   Re: UPDATEDs slowing SELECTs in a fully cached database Jeff Janes

15 July 2011

• 06:40   Hardware advice for scalable warehouse db chris
• 07:10   Re: Hardware advice for scalable warehouse db Greg Smith
• 07:43   Re: Inoptimal query plan for max() and multicolumn index Gaetano Mendola
• 07:43   Re: Inoptimal query plan for max() and multicolumn index Gaetano Mendola
• 08:23   Re: Hardware advice for scalable warehouse db jesper@krogh.cc
• 15:20   Unexpected seq scans when expected result is 1 row out of milions Svetlin Manavski
• 16:49   Re: Hardware advice for scalable warehouse db Robert Schnabel
• 17:59   Re: Unexpected seq scans when expected result is 1 row out of milions Tom Lane
• 18:00   Re: Hardware advice for scalable warehouse db Scott Marlowe
• 18:01   Re: Hardware advice for scalable warehouse db Scott Marlowe
• 18:46   Re: Hardware advice for scalable warehouse db Josh Berkus
• 18:56   Re: Hardware advice for scalable warehouse db chris r.
• 19:26   Re: Hardware advice for scalable warehouse db Rob Wultsch
• 19:46   Re: Hardware advice for scalable warehouse db Josh Berkus
• 21:41   Re: Statistics and Multi-Column indexes lars

16 July 2011

• 00:22   Re: UPDATEDs slowing SELECTs in a fully cached database lars
• 22:33   Re: UPDATEDs slowing SELECTs in a fully cached database Jeff Janes

17 July 2011

• 02:13   Re: UPDATEDs slowing SELECTs in a fully cached database lars

18 July 2011

• 00:44   Re: UPDATEDs slowing SELECTs in a fully cached database Greg Smith
• 01:43   BBU still needed with SSD? Andy
• 02:30   Re: BBU still needed with SSD? Craig Ringer
• 07:56   Re: BBU still needed with SSD? Yeb Havinga
• 19:48   cpu comparison M. D.
• 20:11   Re: cpu comparison ktm@rice.edu
• 21:56   Re: cpu comparison Tomas Vondra
• 22:03   Re: cpu comparison Josh Berkus
• 23:19   Re: cpu comparison ktm@rice.edu
• 23:37   Re: BBU still needed with SSD? David Rees

19 July 2011

• 00:40   Re: BBU still needed with SSD? Greg Smith
• 00:47   Re: cpu comparison Greg Smith
• 01:33   Re: BBU still needed with SSD? Andy
• 01:38   Re: cpu comparison Scott Marlowe
• 02:00   Re: BBU still needed with SSD? Bruce Momjian
• 03:25   Re: cpu comparison M. D.
• 03:56   Re: BBU still needed with SSD? Andy
• 05:06   Re: cpu comparison Samuel Gendler
• 07:57   Re: BBU still needed with SSD? Florian Weimer
• 10:19   Re: BBU still needed with SSD? Greg Smith
• 10:35   Re: BBU still needed with SSD? Yeb Havinga
• 10:47   Re: BBU still needed with SSD? Florian Weimer
• 11:25   Re: BBU still needed with SSD? Yeb Havinga
• 11:37   Re: BBU still needed with SSD? Florian Weimer
• 12:16   Re: BBU still needed with SSD? Yeb Havinga
• 14:29   Re: BBU still needed with SSD? Greg Smith
• 20:08   Re: hstore - Implementation and performance issues around its operators Robert Haas
• 20:28   Re: Large rows number, and large objects Robert Haas
• 20:32   Re: bad plan: 8.4.8, hashagg, work_mem=1MB. Robert Haas
• 21:07   Re: hstore - Implementation and performance issues around its operators Stefan Keller

20 July 2011

• 15:57   Re: Large rows number, and large objects Jose Ildefonso Camargo Tolosa
• 19:30   Re: Large rows number, and large objects Robert Haas
• 19:39   Re: Large rows number, and large objects Andrzej Nakonieczny

21 July 2011

• 07:26   Re: BBU still needed with SSD? Klaus Ita
• 11:16   Intel 320 series drives firmware bug Greg Smith

22 July 2011

• 00:46   Re: Large rows number, and large objects Jose Ildefonso Camargo Tolosa
• 17:08   Re: hstore - Implementation and performance issues around its operators Robert Haas

24 July 2011

• 14:06   Bad query plan Дмитрий Васильев
• 16:02   Re: Bad query plan Tom Lane

25 July 2011

• 06:38   Restore database after drop command Adarsh Sharma
• 07:11   Re: [ADMIN] Restore database after drop command Adarsh Sharma
• 10:51   Re: [ADMIN] Restore database after drop command Florian Weimer
• 18:15   Re: [ADMIN] Restore database after drop command Tomas Vondra

27 July 2011

• 14:16   Re: UPDATEDs slowing SELECTs in a fully cached database Pavan Deolasee
• 17:01   Re: Hardware advice for scalable warehouse db Terry Schmitt

29 July 2011

• 00:25   Re: very large record sizes and ressource usage Robert Haas
• 13:37   Queries related to checkpoints Rohan Malhotra
• 15:25   Re: Queries related to checkpoints Kevin Grittner
• 17:26   Re: Trigger or Function alan
• 17:26   Re: Bad query plan Gavin Flower
• 17:26   Re: [ADMIN] Restore database after drop command Vibhor Kumar
• 17:26   Re: insert alan
• 17:26   heavy load-high cpu itilization Filippos
• 17:26   insert alan
• 17:26   Performance penalty when using WITH Li Jin
• 17:26   Re: UPDATEDs slowing SELECTs in a fully cached database lars hofhansl
• 17:26   issue related to logging facility of postgres shailesh singh
• 17:40   Re: Performance penalty when using WITH Tom Lane
• 19:54   Re: heavy load-high cpu itilization Scott Marlowe
• 20:14   Re: insert Kevin Grittner

30 July 2011

• 13:10   Re: Performance penalty when using WITH Robert Klemme

31 July 2011

• 12:17   Re: heavy load-high cpu itilization Filippos
• 21:25   Re: Trigger or Function Gavin Flower
• 21:25   Re: insert Gavin Flower
• 21:25   Re: heavy load-high cpu itilization Filippos
• 21:25   Performance die when COPYing to table with bigint PK Robert Ayrapetyan