Mailing lists [pgsql-performance]

1 April 2009

• 08:13   Re: Raid 10 chunksize Mark Kirkwood
• 08:27   Re: Raid 10 chunksize Mark Kirkwood
• 09:10   PostgreSQL Mahu Vasile
• 12:22   Re: How to get parallel restore in PG 8.4 to work? henk de wit
• 13:46   Re: How to get parallel restore in PG 8.4 to work? Tom Lane
• 14:23   Re: PostgreSQL Robert Haas
• 14:46   Re: Raid 10 chunksize Stef Telford
• 16:08   Re: Raid 10 chunksize Greg Smith
• 16:15   Re: Raid 10 chunksize Stef Telford
• 16:36   self join revisited Rikard Pavelic
• 16:41   Re: Raid 10 chunksize Scott Marlowe
• 16:46   Re: self join revisited Matthew Wakeling
• 16:49   Re: Raid 10 chunksize Stef Telford
• 16:51   Re: Raid 10 chunksize Matthew Wakeling
• 16:55   Re: Raid 10 chunksize Scott Marlowe
• 17:01   Re: Raid 10 chunksize Matthew Wakeling
• 17:04   Re: Raid 10 chunksize Scott Marlowe
• 17:10   Re: Very specialised query Matthew Wakeling
• 17:17   Re: Raid 10 chunksize Stef Telford
• 17:19   Re: self join revisited Tom Lane
• 17:33   Re: Very specialised query Matthew Wakeling
• 17:49   Re: Raid 10 chunksize Greg Smith
• 17:54   Re: Raid 10 chunksize Matthew Wakeling
• 17:58   Re: Raid 10 chunksize Scott Marlowe
• 18:27   Re: Very specialised query Matthew Wakeling
• 18:42   Re: self join revisited Rikard Pavelic
• 19:51   Re: Raid 10 chunksize Stef Telford
• 20:38   Re: Raid 10 chunksize david@lang.hm
• 20:44   Re: Raid 10 chunksize Stef Telford
• 20:47   Re: Raid 10 chunksize david@lang.hm
• 21:14   Re: self join revisited Robert Haas
• 22:14   Re: Raid 10 chunksize Scott Carey
• 22:15   Re: Raid 10 chunksize Scott Carey
• 22:17   Re: Raid 10 chunksize Scott Carey
• 22:36   Re: Raid 10 chunksize Scott Carey
• 22:59   Re: Raid 10 chunksize david@lang.hm
• 23:39   Re: Raid 10 chunksize Scott Marlowe

2 April 2009

• 06:19   Re: Raid 10 chunksize Mark Kirkwood
• 06:31   Re: Raid 10 chunksize Mark Kirkwood
• 08:53   Re: Raid 10 chunksize Greg Smith
• 15:02   Re: Very specialised query Matthew Wakeling
• 16:36   Re: Very specialised query Craig Ringer
• 17:58   Re: Raid 10 chunksize Merlin Moncure
• 19:25   Re: Raid 10 chunksize James Mansion
• 20:18   Re: How to get parallel restore in PG 8.4 to work? henk de wit
• 20:20   Re: Raid 10 chunksize Scott Carey
• 20:27   Re: Raid 10 chunksize Merlin Moncure
• 20:34   Re: Raid 10 chunksize Scott Carey
• 20:44   Re: Raid 10 chunksize Scott Carey
• 23:09   Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 Bruce Momjian

3 April 2009

• 00:17   Re: Raid 10 chunksize Ron Mayer
• 08:24   Re: Raid 10 chunksize Hannes Dorbath
• 08:54   Re: Raid 10 chunksize Mark Kirkwood
• 09:29   Re: Raid 10 chunksize Greg Smith
• 09:53   Re: Raid 10 chunksize Greg Smith
• 10:30   Re: Raid 10 chunksize Greg Smith
• 13:18   Rewriting using rules for performance Matthew Wakeling
• 13:32   plpgsql arrays Matthew Wakeling
• 13:46   Re: Rewriting using rules for performance Robert Haas
• 13:47   Re: plpgsql arrays Robert Haas
• 13:55   Re: Rewriting using rules for performance Matthew Wakeling
• 13:57   Re: plpgsql arrays Matthew Wakeling
• 14:04   Re: plpgsql arrays Tom Lane
• 14:08   Re: plpgsql arrays Tom Lane
• 14:15   Re: plpgsql arrays Matthew Wakeling
• 14:24   Re: plpgsql arrays Tom Lane
• 14:28   Re: plpgsql arrays Matthew Wakeling
• 14:45   Re: plpgsql arrays Matthew Wakeling
• 14:48   Re: plpgsql arrays Tom Lane
• 14:58   Re: plpgsql arrays Matthew Wakeling
• 15:02   Re: plpgsql arrays Merlin Moncure
• 15:09   Re: plpgsql arrays Merlin Moncure
• 15:15   Re: plpgsql arrays Matthew Wakeling
• 15:18   Re: plpgsql arrays Merlin Moncure
• 15:52   Re: Rewriting using rules for performance Merlin Moncure
• 15:59   Re: Rewriting using rules for performance Merlin Moncure
• 17:29   Re: plpgsql arrays Simon Riggs
• 17:33   Re: plpgsql arrays Alvaro Herrera
• 17:39   Re: plpgsql arrays Tom Lane
• 19:03   Re: plpgsql arrays Nathan Boley
• 19:53   Question on pgbench output David Kerr
• 20:43   Re: Question on pgbench output Tom Lane
• 21:18   Re: Question on pgbench output David Kerr
• 21:43   Re: Question on pgbench output Scott Marlowe
• 21:51   Re: Question on pgbench output Greg Smith
• 22:30   Re: Question on pgbench output Tom Lane
• 22:52   Re: Question on pgbench output Tom Lane
• 23:13   Using IOZone to simulate DB access patterns Josh Berkus
• 23:35   Re: Question on pgbench output David Kerr
• 23:47   Re: Question on pgbench output David Kerr

4 April 2009

• 00:10   Re: Using IOZone to simulate DB access patterns Josh Berkus
• 01:05   Re: Raid 10 chunksize david@lang.hm
• 02:26   Re: Raid 10 chunksize Greg Smith
• 02:36   Re: Question on pgbench output Greg Smith
• 05:25   Re: Raid 10 chunksize Scott Carey
• 10:00   Re: Using IOZone to simulate DB access patterns henk de wit
• 10:49   Re: Using IOZone to simulate DB access patterns Jesper Krogh
• 15:54   Re: Using IOZone to simulate DB access patterns henk de wit
• 16:08   Re: Strange behavior: pgbench and new Linux kernels Greg Smith
• 18:55   Re: Strange behavior: pgbench and new Linux kernels Josh Berkus
• 20:11   Re: Strange behavior: pgbench and new Linux kernels Greg Smith

5 April 2009

• 04:06   Re: Question on pgbench output David Kerr
• 07:01   Re: Question on pgbench output Simon Riggs
• 15:47   Re: Question on pgbench output Tom Lane
• 17:12   Re: Question on pgbench output David Kerr
• 17:43   Re: Question on pgbench output Tom Lane
• 18:36   Best replication solution? Lists
• 21:57   Re: Best replication solution? Lists
• 23:33   difficulties with time based queries Rainer Mager
• 23:46   Re: difficulties with time based queries David Wilson
• 23:56   Re: difficulties with time based queries PFC

6 April 2009

• 00:12   Re: difficulties with time based queries Tom Lane
• 01:25   Re: difficulties with time based queries Rainer Mager
• 01:33   Re: difficulties with time based queries Tom Lane
• 02:11   Re: Best replication solution? Greg Sabino Mullane
• 03:35   Re: difficulties with time based queries Rainer Mager
• 07:10   probelm with alter table add constraint...... roopasatish
• 08:27   Re: Best replication solution? Heikki Linnakangas
• 10:37   Re: difficulties with time based queries Robert Haas
• 10:43   Re: probelm with alter table add constraint...... Robert Haas
• 10:47   Re: probelm with alter table add constraint...... Albe Laurenz
• 11:47   Re: plpgsql arrays Matthew Wakeling
• 12:21   Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance Mario Splivalo
• 12:24   Re: difficulties with time based queries Matthew Wakeling
• 12:41   Re: Best replication solution? Andrew Sullivan
• 12:52   Re: plpgsql arrays Matthew Wakeling
• 13:54   Re: probelm with alter table add constraint...... Tom Lane
• 14:03   Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance Scott Marlowe
• 14:36   Re: plpgsql arrays Robert Haas
• 14:38   Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance Mario Splivalo
• 14:47   Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance Scott Marlowe
• 14:51   Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance Mario Splivalo
• 15:23   Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance Scott Marlowe

7 April 2009

• 03:44   Re: Best replication solution? Lists
• 04:06   Re: Best replication solution? Lists
• 09:36   Re: Best replication solution? Dimitri Fontaine
• 10:11   Re: Best replication solution? Ivan Voras
• 10:31   Re: Best replication solution? Mark Kirkwood
• 15:18   Re: plpgsql arrays Matthew Wakeling
• 15:24   Re: plpgsql arrays justin
• 15:33   Re: plpgsql arrays Matthew Wakeling
• 15:45   Re: plpgsql arrays justin
• 16:08   Re: plpgsql arrays Tom Lane
• 16:21   Re: Best replication solution? Andrew Sullivan
• 16:22   Re: plpgsql arrays Matthew Wakeling
• 17:18   Re: Best replication solution? Andrew Sullivan
• 18:06   determining the locks that will be held by a query Brian Cox
• 19:24   Re: plpgsql arrays Merlin Moncure
• 19:32   Re: plpgsql arrays Tom Lane
• 22:49   Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 Bruce Momjian

8 April 2009

• 07:15   Re: Best replication solution? Mark Kirkwood
• 10:35   Re: plpgsql arrays Matthew Wakeling
• 11:45   Re: Best replication solution? Marinos Yannikos
• 13:42   bad query plans for ~ "^string" (and like "string%") (8.3.6) Marinos Yannikos
• 13:51   Re: bad query plans for ~ "^string" (and like "string%") (8.3.6) Marinos Yannikos
• 13:54   Re: bad query plans for ~ "^string" (and like "string%") (8.3.6) Robert Haas
• 14:28   Re: bad query plans for ~ "^string" (and like "string%") (8.3.6) Tom Lane
• 19:20   Re: Best replication solution? Jeff
• 20:47   Re: Best replication solution? Dimitri Fontaine
• 21:09   Nested query performance issue Glenn Maynard
• 21:30   Re: Nested query performance issue Віталій Тимчишин
• 21:55   Re: Nested query performance issue Glenn Maynard
• 22:49   Re: difficulties with time based queries Rainer Mager

9 April 2009

• 09:25   Re: Nested query performance issue Віталій Тимчишин
• 11:29   Re: Nested query performance issue Heikki Linnakangas
• 12:19   Re: Best replication solution? Jeff
• 14:01   linux deadline i/o elevator tuning Mark Wong
• 14:10   Re: linux deadline i/o elevator tuning Kevin Grittner
• 14:27   Re: linux deadline i/o elevator tuning Grzegorz Jaśkiewicz
• 14:32   Re: linux deadline i/o elevator tuning Matthew Wakeling
• 14:39   Re: linux deadline i/o elevator tuning Grzegorz Jaśkiewicz
• 14:40   Re: linux deadline i/o elevator tuning Kevin Grittner
• 14:42   Re: linux deadline i/o elevator tuning Kevin Grittner
• 14:47   Re: linux deadline i/o elevator tuning Matthew Wakeling
• 14:48   Re: linux deadline i/o elevator tuning Grzegorz Jaśkiewicz
• 14:49   Re: linux deadline i/o elevator tuning Arjen van der Meijden
• 14:53   Re: linux deadline i/o elevator tuning Mark Wong
• 14:58   Re: linux deadline i/o elevator tuning Kevin Grittner
• 15:09   Re: linux deadline i/o elevator tuning Mark Wong
• 22:50   Re: linux deadline i/o elevator tuning Scott Carey
• 23:42   Re: Nested query performance issue Glenn Maynard
• 23:42   Re: Nested query performance issue Glenn Maynard
• 23:59   Re: Nested query performance issue Greg Smith

10 April 2009

• 05:08   Re: difficulties with time based queries Rainer Mager
• 05:20   Re: difficulties with time based queries Tom Lane
• 05:41   Re: Using IOZone to simulate DB access patterns Josh Berkus
• 06:11   Re: Nested query performance issue Glenn Maynard
• 06:27   Re: Using IOZone to simulate DB access patterns Mark Kirkwood
• 06:43   Shouldn't the planner have a higher cost for reverse index scans? Josh Berkus
• 06:48   Re: linux deadline i/o elevator tuning Albe Laurenz *EXTERN*
• 10:20   Postgres 8.x on Windows Server in production Ognjen Blagojevic
• 13:42   Re: Nested query performance issue Tom Lane
• 13:50   Re: Shouldn't the planner have a higher cost for reverse index scans? Tom Lane
• 16:00   Re: Using IOZone to simulate DB access patterns Joshua D. Drake
• 17:07   Re: Shouldn't the planner have a higher cost for reverse index scans? Josh Berkus
• 17:10   Re: Using IOZone to simulate DB access patterns Josh Berkus
• 17:11   Re: Using IOZone to simulate DB access patterns Scott Carey
• 17:15   Re: Using IOZone to simulate DB access patterns Josh Berkus
• 17:19   Re: Shouldn't the planner have a higher cost for reverse index scans? Tom Lane
• 17:31   Re: Using IOZone to simulate DB access patterns Josh Berkus
• 17:40   Re: Using IOZone to simulate DB access patterns Scott Carey
• 17:46   Re: Shouldn't the planner have a higher cost for reverse index scans? Josh Berkus
• 17:57   Re: plpgsql arrays Tom Lane
• 18:01   Re: Using IOZone to simulate DB access patterns Greg Smith
• 18:07   Re: Postgres 8.x on Windows Server in production Josh Berkus
• 18:17   Re: Using IOZone to simulate DB access patterns Scott Carey
• 19:05   determining the locks that will be held by a query Brian Cox
• 19:25   Re: Using IOZone to simulate DB access patterns Greg Smith
• 20:02   Re: determining the locks that will be held by a query Kevin Grittner
• 20:06   2.6.26 kernel and PostgreSQL Glyn Astill
• 20:17   Re: 2.6.26 kernel and PostgreSQL Kevin Grittner
• 20:40   Re: Postgres 8.x on Windows Server in production Grzegorz Jaśkiewicz
• 22:00   Re: 2.6.26 kernel and PostgreSQL Glyn Astill

11 April 2009

• 00:03   Re: Using IOZone to simulate DB access patterns M. Edward (Ed) Borasky
• 18:44   Re: Using IOZone to simulate DB access patterns Mark Wong

12 April 2009

• 02:00   Re: Using IOZone to simulate DB access patterns Scott Carey
• 23:13   Re: Postgres 8.x on Windows Server in production Rainer Mager
• 23:41   Re: Postgres 8.x on Windows Server in production Scott Marlowe
• 23:49   Re: Postgres 8.x on Windows Server in production Rainer Mager
• 23:58   Re: Postgres 8.x on Windows Server in production Scott Marlowe

13 April 2009

• 08:26   Re: 2.6.26 kernel and PostgreSQL Greg Smith
• 11:49   Re: 2.6.26 kernel and PostgreSQL Glyn Astill
• 13:23   Re: Postgres 8.x on Windows Server in production Ognjen Blagojevic
• 14:13   Re: linux deadline i/o elevator tuning Jeff
• 15:18   Re: linux deadline i/o elevator tuning Kevin Grittner
• 16:45   Re: Postgres 8.x on Windows Server in production Scott Marlowe
• 19:14   Re: Postgres 8.x on Windows Server in production Grzegorz Jaśkiewicz

14 April 2009

• 00:48   Re: Postgres 8.x on Windows Server in production Justin Pitts
• 07:57   INSERT times - same storage space but more fields -> much slower inserts Craig Ringer
• 09:19   Re: difficulties with time based queries PFC
• 09:33   Re: Nested query performance issue Matthew Wakeling
• 09:39   Re: Shouldn't the planner have a higher cost for reverse index scans? Matthew Wakeling
• 10:04   Re: Nested query performance issue Glenn Maynard
• 13:46   Re: Nested query performance issue Merlin Moncure
• 15:57   Re: INSERT times - same storage space but more fields -> much slower inserts Stephen Frost
• 16:00   Re: difficulties with time based queries Nikolas Everett
• 16:01   Re: INSERT times - same storage space but more fields -> much slower inserts Matthew Wakeling
• 16:22   Re: INSERT times - same storage space but more fields -> much slower inserts Stephen Frost

15 April 2009

• 00:31   Re: INSERT times - same storage space but more fields -> much slower inserts Craig Ringer
• 00:44   Re: INSERT times - same storage space but more fields -> much slower inserts Tom Lane
• 00:46   error updating a very large table Brian Cox
• 01:01   Re: INSERT times - same storage space but more fields -> much slower inserts Stephen Frost
• 11:19   Re: error updating a very large table Grzegorz Jaśkiewicz
• 11:21   need information Peeyush
• 11:50   Re: INSERT times - same storage space but more fields -> much slower inserts Matthew Wakeling
• 11:58   Re: INSERT times - same storage space but more fields -> much slower inserts Matthew Wakeling
• 13:52   Re: error updating a very large table Tom Lane
• 17:10   Re: error updating a very large table Simon Riggs

16 April 2009

• 06:42   Re: Shouldn't the planner have a higher cost for reverse index scans? Lists
• 08:12   Re: Shouldn't the planner have a higher cost for reverse index scans? Grzegorz Jaśkiewicz
• 10:37   Really dumb planner decision Matthew Wakeling
• 10:48   Re: Really dumb planner decision Grzegorz Jaśkiewicz
• 11:16   Re: Really dumb planner decision Grzegorz Jaśkiewicz
• 11:24   Re: Really dumb planner decision Matthew Wakeling
• 11:31   Re: Really dumb planner decision Matthew Wakeling
• 11:42   Re: Really dumb planner decision Robert Haas
• 12:05   Re: Really dumb planner decision Matthew Wakeling
• 12:06   Re: Shouldn't the planner have a higher cost for reverse index scans? Merlin Moncure
• 12:11   Re: Really dumb planner decision Merlin Moncure
• 13:49   Re: Really dumb planner decision Tom Lane
• 14:11   Re: Really dumb planner decision Kevin Grittner
• 14:49   Re: Really dumb planner decision Merlin Moncure
• 15:37   Re: Shouldn't the planner have a higher cost for reverse index scans? Tom Lane
• 15:43   Re: Shouldn't the planner have a higher cost for reverse index scans? Tom Lane
• 15:49   Re: Really dumb planner decision Robert Haas
• 15:52   Re: Shouldn't the planner have a higher cost for reverse index scans? Lists
• 15:54   Re: Really dumb planner decision Matthew Wakeling
• 16:01   Re: Shouldn't the planner have a higher cost for reverse index scans? Tom Lane
• 16:04   Re: Really dumb planner decision Tom Lane
• 16:06   GiST index performance Matthew Wakeling
• 16:33   Re: GiST index performance Kevin Grittner
• 16:38   Re: GiST index performance Matthew Wakeling
• 16:57   Re: GiST index performance Tom Lane
• 17:23   Re: GiST index performance Matthew Wakeling
• 17:26   Re: GiST index performance dforum
• 17:52   Re: GiST index performance Tom Lane
• 17:54   Re: GiST index performance Matthew Wakeling
• 17:59   Re: GiST index performance Tom Lane
• 18:05   Re: GiST index performance Matthew Wakeling
• 23:09   No hash join across partitioned tables? Kris Jurka
• 23:12   Re: No hash join across partitioned tables? Tom Lane
• 23:30   Re: No hash join across partitioned tables? Kris Jurka

17 April 2009

• 01:02   Re: No hash join across partitioned tables? Kris Jurka
• 01:22   Re: GiST index performance Craig Ringer
• 04:50   Optimizer's issue Vlad Arkhipov
• 15:02   Re: No hash join across partitioned tables? Tom Lane
• 15:08   Re: No hash join across partitioned tables? Tom Lane
• 15:12   Re: No hash join across partitioned tables? Kris Jurka
• 17:05   Re: No hash join across partitioned tables? Kris Jurka
• 17:18   Re: GiST index performance Matthew Wakeling
• 23:12   stats are way off on 8.4 b1 Grzegorz Jaśkiewicz
• 23:30   Re: stats are way off on 8.4 b1 Tom Lane
• 23:40   Re: stats are way off on 8.4 b1 Grzegorz Jaśkiewicz

18 April 2009

• 07:00   Re: stats are way off on 8.4 b1 Heikki Linnakangas
• 12:02   Re: stats are way off on 8.4 b1 Grzegorz Jaśkiewicz

19 April 2009

• 23:31   Re: No hash join across partitioned tables? Tom Lane

20 April 2009

• 13:55   SQL With Dates Rafael Domiciano
• 14:11   Re: GiST index performance Matthew Wakeling
• 14:16   Re: SQL With Dates Grzegorz Jaśkiewicz
• 15:27   Re: GiST index performance Tom Lane
• 18:48   Re: SQL With Dates Rafael Domiciano
• 18:59   Re: SQL With Dates Scott Marlowe
• 20:17   Re: SQL With Dates Mark Lewis
• 21:53   performance for high-volume log insertion david@lang.hm

21 April 2009

• 01:55   Re: performance for high-volume log insertion Stephen Frost
• 02:24   Re: performance for high-volume log insertion david@lang.hm
• 02:51   Re: performance for high-volume log insertion Stephen Frost
• 03:12   Re: performance for high-volume log insertion Greg Smith
• 03:15   Re: performance for high-volume log insertion Stephen Frost
• 03:30   Re: performance for high-volume log insertion david@lang.hm
• 04:10   Re: performance for high-volume log insertion Stephen Frost
• 06:01   Re: performance for high-volume log insertion david@lang.hm
• 06:05   Re: performance for high-volume log insertion david@lang.hm
• 06:08   Re: performance for high-volume log insertion david@lang.hm
• 06:41   Re: performance for high-volume log insertion Stephen Frost
• 06:46   Re: performance for high-volume log insertion Stephen Frost
• 06:51   Re: performance for high-volume log insertion Stephen Frost
• 07:50   Re: performance for high-volume log insertion david@lang.hm
• 08:26   Re: performance for high-volume log insertion david@lang.hm
• 08:56   Re: performance for high-volume log insertion Richard Huxton
• 10:40   Re: GiST index performance Matthew Wakeling
• 13:33   Re: performance for high-volume log insertion Kenneth Marshall
• 14:21   WHERE condition not being pushed down to union parts John L. Clark
• 14:35   Re: WHERE condition not being pushed down to union parts Tom Lane
• 14:41   Re: WHERE condition not being pushed down to union parts John L. Clark
• 14:50   Re: WHERE condition not being pushed down to union parts Tom Lane
• 15:38   Re: performance for high-volume log insertion david@lang.hm
• 15:52   Re: performance for high-volume log insertion Kenneth Marshall
• 15:57   Re: SQL With Dates Robert Haas
• 16:03   Re: performance for high-volume log insertion Ben Chobot
• 16:38   Re: performance for high-volume log insertion Stephen Frost
• 16:59   Re: performance for high-volume log insertion david@lang.hm
• 17:17   Re: performance for high-volume log insertion Greg Smith
• 17:26   Re: performance for high-volume log insertion Stephen Frost
• 18:09   Re: performance for high-volume log insertion david@lang.hm
• 18:12   Re: WHERE condition not being pushed down to union parts John L. Clark
• 18:34   Re: performance for high-volume log insertion Kenneth Marshall
• 18:35   Re: performance for high-volume log insertion david@lang.hm
• 18:44   Re: performance for high-volume log insertion david@lang.hm
• 19:15   Re: performance for high-volume log insertion Stephen Frost
• 19:17   Re: performance for high-volume log insertion Stephen Frost
• 19:22   Re: performance for high-volume log insertion James Mansion
• 19:25   Re: performance for high-volume log insertion Stephen Frost
• 19:58   Re: WHERE condition not being pushed down to union parts Tom Lane

22 April 2009

• 00:01   Re: performance for high-volume log insertion Greg Smith
• 00:13   Re: performance for high-volume log insertion david@lang.hm
• 02:29   Re: performance for high-volume log insertion Robert Haas
• 05:26   Re: performance for high-volume log insertion James Mansion
• 07:16   Re: probelm with alter table add constraint...... roopabenzer
• 12:19   Re: performance for high-volume log insertion Stephen Frost
• 12:44   Re: performance for high-volume log insertion Stephen Frost
• 13:53   Re: GiST index performance Matthew Wakeling
• 15:18   Re: performance for high-volume log insertion Simon Riggs
• 16:06   Re: GiST index performance Matthew Wakeling
• 19:38   Re: performance for high-volume log insertion Glenn Maynard
• 20:07   Re: performance for high-volume log insertion david@lang.hm
• 20:37   Re: performance for high-volume log insertion Stephen Frost
• 20:49   Re: performance for high-volume log insertion Tom Lane
• 20:53   Re: performance for high-volume log insertion James Mansion
• 21:11   Re: performance for high-volume log insertion Glenn Maynard
• 21:18   Re: performance for high-volume log insertion Joshua D. Drake
• 21:20   Re: performance for high-volume log insertion Glenn Maynard
• 21:48   Re: performance for high-volume log insertion Glenn Maynard
• 21:51   Re: performance for high-volume log insertion Stephen Frost
• 22:16   Re: performance for high-volume log insertion Glenn Maynard
• 22:46   Re: performance for high-volume log insertion david@lang.hm

23 April 2009

• 01:48   Re: performance for high-volume log insertion Stephen Frost
• 01:50   Re: performance for high-volume log insertion Stephen Frost
• 02:26   Re: performance for high-volume log insertion Glenn Maynard
• 04:56   Re: performance for high-volume log insertion david@lang.hm
• 11:04   Re: performance for high-volume log insertion Stephen Frost
• 11:11   Re: performance for high-volume log insertion Stephen Frost
• 16:09   Re: WHERE condition not being pushed down to union parts John L. Clark
• 16:15   Re: WHERE condition not being pushed down to union parts Tom Lane
• 22:15   Re: performance for high-volume log insertion Thomas Kellerer
• 23:01    Adam Ruth

26 April 2009

• 17:08   Re: performance for high-volume log insertion Kris Jurka
• 17:35   Re: performance for high-volume log insertion Thomas

27 April 2009

• 03:28   Re: Using IOZone to simulate DB access patterns Mark Wong
• 03:45   Re: Using IOZone to simulate DB access patterns Mark Wong
• 06:29   Re: performance for high-volume log insertion Scott Marlowe
• 06:45   Re: performance for high-volume log insertion Kris Jurka
• 07:07   Re: performance for high-volume log insertion Scott Marlowe
• 07:14   Re: performance for high-volume log insertion david@lang.hm
• 09:39   plpgsql function running long, but resources consumption is very low Wojtek
• 09:56   Re: plpgsql function running long, but resources consumption is very low Pavel Stehule
• 15:33   Re: Using IOZone to simulate DB access patterns Laurent Laborde
• 19:08   Re: plpgsql function running long, but resources consumption is very low Scott Carey

28 April 2009

• 09:53   any interest of changing the page size ? Laurent Laborde
• 16:56   partition question for new server setup Whit Armstrong
• 17:37   Re: partition question for new server setup Scott Marlowe
• 17:48   Re: partition question for new server setup Whit Armstrong
• 17:53   pg_lock_status() performance Merlin Moncure
• 17:56   Re: partition question for new server setup Scott Marlowe
• 18:06   Re: partition question for new server setup Kenneth Marshall
• 18:13   Re: partition question for new server setup Craig James
• 18:23   Re: partition question for new server setup Alan Hodgson
• 18:23   Re: partition question for new server setup Craig James
• 18:31   Re: partition question for new server setup Kevin Grittner
• 18:47   Re: partition question for new server setup Whit Armstrong
• 18:47   Re: partition question for new server setup Kenneth Marshall
• 19:13   Re: partition question for new server setup Kevin Grittner
• 19:15   Re: partition question for new server setup Whit Armstrong
• 19:15   Re: partition question for new server setup Scott Marlowe
• 19:17   Re: partition question for new server setup Scott Marlowe
• 19:19   Re: partition question for new server setup Scott Marlowe
• 21:41   Re: pg_lock_status() performance Tom Lane
• 21:42   Re: pg_lock_status() performance Merlin Moncure
• 21:43   Re: pg_lock_status() performance Merlin Moncure
• 22:17   Re: pg_lock_status() performance Tom Lane
• 23:40   Re: partition question for new server setup Scott Carey
• 23:58   Re: partition question for new server setup Scott Carey

29 April 2009

• 00:02   Re: partition question for new server setup Whit Armstrong
• 00:11   Re: partition question for new server setup Whit Armstrong
• 00:20   Re: partition question for new server setup Scott Marlowe
• 01:32   Re: partition question for new server setup Scott Carey
• 01:59   Re: partition question for new server setup Scott Carey
• 19:08   Re: partition question for new server setup Scott Carey

30 April 2009

• 21:16   Re: partition question for new server setup Whit Armstrong