Mailing lists [pgsql-performance]

1 May 2009

• 02:40   Re: partition question for new server setup Whit Armstrong
• 08:15   bad plan and LIMIT James Nelson
• 09:57   Re: bad plan and LIMIT Adam Ruth
• 10:14   Re: bad plan and LIMIT Grzegorz Jaśkiewicz
• 11:12   Re: bad plan and LIMIT Grzegorz Jaśkiewicz
• 13:56   Many left outer joins with limit performance Gerhard Wiesinger
• 14:32   Transparent table partitioning in future version of PG? henk de wit
• 14:57   Re: bad plan and LIMIT Tom Lane
• 15:05   Re: bad plan and LIMIT James Nelson
• 15:07   Re: bad plan and LIMIT James Nelson
• 15:27   Re: Transparent table partitioning in future version of PG? Robert Haas
• 15:42   Re: bad plan and LIMIT James Nelson
• 16:14   Re: Many left outer joins with limit performance Tom Lane
• 17:25   Re: Transparent table partitioning in future version of PG? Scott Carey

2 May 2009

• 00:30   Re: performance for high-volume log insertion PFC
• 01:04   Re: performance for high-volume log insertion david@lang.hm
• 04:20   Re: performance for high-volume log insertion Glenn Maynard

4 May 2009

• 08:15   high shared buffer and swap Laurent Laborde
• 08:57   Re: high shared buffer and swap Greg Stark
• 10:35   Re: [HACKERS] high shared buffer and swap Martijn van Oosterhout
• 15:07   Re: high shared buffer and swap Scott Marlowe

5 May 2009

• 07:31   Limit I/O bandwidth of a certain backend Vlad Arkhipov
• 09:09   Re: [HACKERS] high shared buffer and swap PFC
• 10:27   Re: [HACKERS] high shared buffer and swap Laurent Laborde
• 11:42   Re: [HACKERS] high shared buffer and swap Matthew Wakeling

6 May 2009

• 00:55   Re: Limit I/O bandwidth of a certain backend Bryan Murphy
• 05:11   Re: Limit I/O bandwidth of a certain backend Greg Smith
• 07:42   Any better plan for this query?.. Dimitri
• 08:12   Re: Any better plan for this query?.. Craig Ringer
• 08:18   Re: Any better plan for this query?.. Dimitri
• 08:21   Re: Any better plan for this query?.. Heikki Linnakangas
• 08:24   Re: Any better plan for this query?.. Chris
• 08:33   Re: Any better plan for this query?.. Dimitri
• 08:33   Re: Any better plan for this query?.. Dimitri
• 08:52   Re: Any better plan for this query?.. Dimitri
• 08:54   Re: Any better plan for this query?.. Richard Huxton
• 09:06   Re: Any better plan for this query?.. Richard Huxton
• 09:36   Re: Any better plan for this query?.. Matthew Wakeling
• 11:46   Re: Any better plan for this query?.. Merlin Moncure
• 11:47   Re: Any better plan for this query?.. Merlin Moncure
• 12:29   Re: Any better plan for this query?.. Albe Laurenz
• 12:33   Re: Any better plan for this query?.. Dimitri
• 12:49   Re: Any better plan for this query?.. Dimitri
• 12:53   Re: Any better plan for this query?.. Richard Huxton
• 12:59   Re: Any better plan for this query?.. Kenneth Marshall
• 13:05   Re: Any better plan for this query?.. Kenneth Marshall
• 13:29   Re: Any better plan for this query?.. Ries van Twisk
• 14:03   Re: Any better plan for this query?.. Dimitri
• 14:05   Re: Any better plan for this query?.. Craig Ringer
• 14:26   Re: Any better plan for this query?.. Kenneth Marshall
• 14:29   Re: Any better plan for this query?.. Matthew Wakeling
• 14:31   Re: Any better plan for this query?.. Dimitri
• 14:34   Re: Any better plan for this query?.. Kenneth Marshall
• 14:48   Re: Any better plan for this query?.. Dimitri
• 15:49   Re: Any better plan for this query?.. Kenneth Marshall
• 21:32   Re: Transparent table partitioning in future version of PG? Simon Riggs
• 21:34   Re: Any better plan for this query?.. Simon Riggs
• 21:55   Re: Transparent table partitioning in future version of PG? Tom Lane
• 22:07   Re: GiST index performance Tom Lane
• 22:54   Re: Transparent table partitioning in future version of PG? Simon Riggs

7 May 2009

• 02:27   Re: Transparent table partitioning in future version of PG? Tom Lane
• 02:32   Re: Transparent table partitioning in future version of PG? Alvaro Herrera
• 02:56   Re: Transparent table partitioning in future version of PG? Craig Ringer
• 08:20   Re: Any better plan for this query?.. Dimitri
• 08:49   Re: Any better plan for this query?.. Dimitri
• 08:52   Re: Transparent table partitioning in future version of PG? Simon Riggs
• 11:22   Re: GiST index performance Oleg Bartunov
• 11:35   Re: Any better plan for this query?.. Merlin Moncure
• 11:58   Re: Any better plan for this query?.. Gregory Stark
• 12:20   Re: Any better plan for this query?.. Simon Riggs
• 12:39   Re: GiST index performance Matthew Wakeling
• 14:20   Slow select performance despite seemingly reasonable query plan David Brain
• 14:32   Re: Slow select performance despite seemingly reasonable query plan Scott Mead
• 14:49   Re: Slow select performance despite seemingly reasonable query plan David Brain
• 14:53   Re: Slow select performance despite seemingly reasonable query plan Matthew Wakeling
• 15:12   Re: Slow select performance despite seemingly reasonable query plan David Brain
• 15:18   Re: Slow select performance despite seemingly reasonable query plan Nikolas Everett
• 15:19   Re: Slow select performance despite seemingly reasonable query plan Matthew Wakeling
• 15:27   Re: Any better plan for this query?.. Alvaro Herrera
• 15:37   Re: Slow select performance despite seemingly reasonable query plan Nikolas Everett
• 17:01   Bad Plan for Questionnaire-Type Query David Blewett
• 17:28   Re: Bad Plan for Questionnaire-Type Query David Blewett
• 17:37   Re: Transparent table partitioning in future version of PG? Scott Carey
• 18:37   Re: Any better plan for this query?.. Dimitri
• 19:53   Re: Any better plan for this query?.. Simon Riggs
• 20:31   Re: Bad Plan for Questionnaire-Type Query Tom Lane
• 22:41   Re: Bad Plan for Questionnaire-Type Query David Blewett
• 22:44   Re: Bad Plan for Questionnaire-Type Query Tom Lane
• 22:47   Indexes not used in DELETE Viktor Rosenfeld
• 22:56   Re: Bad Plan for Questionnaire-Type Query David Blewett
• 23:07   Re: Indexes not used in DELETE Tom Lane

8 May 2009

• 02:25   Re: Transparent table partitioning in future version of PG? Robert Haas
• 02:52   Re: Transparent table partitioning in future version of PG? david@lang.hm
• 05:47   Rohan Pethkar sent you a Friend Request on Yaari Rohan Pethkar
• 10:18   Re: Indexes not used in DELETE Viktor Rosenfeld
• 13:46   Statistics use with functions Matthew Wakeling
• 15:48   Re: Statistics use with functions Tom Lane
• 16:11   Re: Statistics use with functions Matthew Wakeling
• 16:13   PostgreSQL with PostGIS on embedded hardware Paolo Rizzi
• 16:16   Re: Statistics use with functions Tom Lane
• 16:48   Re: Transparent table partitioning in future version of PG? Robert Haas
• 16:56   Re: PostgreSQL with PostGIS on embedded hardware Joshua D. Drake
• 17:09   Re: Transparent table partitioning in future version of PG? Scott Carey
• 18:25   Re: PostgreSQL with PostGIS on embedded hardware Paolo Rizzi
• 18:47   Re: Transparent table partitioning in future version of PG? david@lang.hm
• 19:17   Re: PostgreSQL with PostGIS on embedded hardware Fernando Hevia
• 19:40   Re: Transparent table partitioning in future version of PG? Scott Carey
• 20:53   Re: Transparent table partitioning in future version of PG? Robert Haas
• 21:04   Re: Transparent table partitioning in future version of PG? Tom Lane
• 23:10   Re: PostgreSQL with PostGIS on embedded hardware Paolo Rizzi
• 23:50   Re: PostgreSQL with PostGIS on embedded hardware PFC

9 May 2009

• 00:02   Re: PostgreSQL with PostGIS on embedded hardware Paolo Rizzi
• 00:08   Re: Bad Plan for Questionnaire-Type Query Tom Lane
• 00:17   Re: PostgreSQL with PostGIS on embedded hardware Tom Lane
• 01:26   Re: Transparent table partitioning in future version of PG? Craig Ringer
• 02:06   Re: Bad Plan for Questionnaire-Type Query Tom Lane
• 09:43   Re: Slow select performance despite seemingly reasonable query plan Laurent Wandrebeck
• 15:44   Re: Bad Plan for Questionnaire-Type Query David Blewett
• 15:52   Re: Bad Plan for Questionnaire-Type Query Tom Lane

10 May 2009

• 20:45   Re: Bad Plan for Questionnaire-Type Query David Blewett

11 May 2009

• 05:47   Reminder: Please Respond to Rohan's Invitation Rohan Pethkar
• 11:41   Re: PostgreSQL with PostGIS on embedded hardware Paolo Rizzi
• 12:42   Re: PostgreSQL with PostGIS on embedded hardware PFC
• 15:18   Re: Any better plan for this query?.. Dimitri
• 15:24   Re: Any better plan for this query?.. Tom Lane
• 16:05   Re: PostgreSQL with PostGIS on embedded hardware Stefan Kaltenbrunner
• 16:15   What is the most optimal config parameters to keep stable write TPS ?.. Dimitri
• 16:20   Re: What is the most optimal config parameters to keep stable write TPS ?.. Kevin Grittner
• 16:30   Re: Any better plan for this query?.. Dimitri
• 16:32   Re: What is the most optimal config parameters to keep stable write TPS ?.. Dimitri
• 16:45   Re: What is the most optimal config parameters to keep stable write TPS ?.. Kevin Grittner
• 17:03   Re: What is the most optimal config parameters to keep stable write TPS ?.. Dimitri
• 17:14   Re: What is the most optimal config parameters to keep stable write TPS ?.. Kevin Grittner
• 17:15   Re: What is the most optimal config parameters to keep stable write TPS ?.. Scott Marlowe
• 17:31   Re: What is the most optimal config parameters to keep stable write TPS ?.. Dimitri
• 17:36   Re: What is the most optimal config parameters to keep stable write TPS ?.. Dimitri
• 17:46   Re: Any better plan for this query?.. Merlin Moncure
• 18:56   Re: Any better plan for this query?.. Simon Riggs
• 19:01   Re: Any better plan for this query?.. Simon Riggs
• 19:46   Re: Any better plan for this query?.. Aidan Van Dyk
• 21:22   Query planner making bad decisions Cory Coager
• 22:30   Re: Any better plan for this query?.. Dimitri
• 22:46   Re: Any better plan for this query?.. Dimitri
• 22:54   Re: Any better plan for this query?.. Alvaro Herrera
• 23:02   Re: Query planner making bad decisions Tom Lane

12 May 2009

• 02:15   Re: What is the most optimal config parameters to keep stable write TPS ?.. Greg Smith
• 02:38   Re: What is the most optimal config parameters to keep stable write TPS ?.. Scott Marlowe
• 05:11   Re: Any better plan for this query?.. Heikki Linnakangas
• 07:35   Re: Any better plan for this query?.. Dimitri
• 07:36   Re: Any better plan for this query?.. Dimitri
• 07:53   Re: Any better plan for this query?.. Andres Freund
• 08:45   Re: Any better plan for this query?.. Dimitri Fontaine
• 09:10   Timestamp index not used in some cases Евгений Василев
• 09:23   Re: What is the most optimal config parameters to keep stable write TPS ?.. Laurent Laborde
• 09:36   Re: What is the most optimal config parameters to keep stable write TPS ?.. Dimitri
• 10:00   Re: Timestamp index not used in some cases Scott Marlowe
• 10:19   Re: Any better plan for this query?.. Dimitri
• 10:47   Re: Any better plan for this query?.. Simon Riggs
• 11:16   Re: Any better plan for this query?.. Dimitri
• 11:31   Re: Any better plan for this query?.. Simon Riggs
• 11:35   Re: Any better plan for this query?.. Heikki Linnakangas
• 11:48   Re: Any better plan for this query?.. Simon Riggs
• 12:05   Re: Query planner making bad decisions Cory Coager
• 12:29   Re: Any better plan for this query?.. Dimitri
• 12:38   Re: Any better plan for this query?.. Stefan Kaltenbrunner
• 12:59   Re: Any better plan for this query?.. Dimitri
• 13:33   Re: Any better plan for this query?.. Dimitri
• 14:14   Re: What is the most optimal config parameters to keep stable write TPS ?.. bock@openit.de (Julian v. Bock)
• 14:34   Re: Any better plan for this query?.. Stefan Kaltenbrunner
• 14:49   Re: Any better plan for this query?.. Robert Haas
• 15:00   Re: Any better plan for this query?.. Matthew Wakeling
• 15:02   Re: Any better plan for this query?.. Simon Riggs
• 15:05   Re: Any better plan for this query?.. Matthew Wakeling
• 15:14   Re: Any better plan for this query?.. Stefan Kaltenbrunner
• 15:18   Re: Any better plan for this query?.. Tom Lane
• 15:30   Re: Any better plan for this query?.. Dimitri
• 15:41   Re: What is the most optimal config parameters to keep stable write TPS ?.. Dimitri
• 15:46   Re: Any better plan for this query?.. Kevin Grittner
• 16:01   Re: Any better plan for this query?.. Dimitri
• 16:09   Re: Any better plan for this query?.. Joshua D. Drake
• 16:17   Re: Any better plan for this query?.. Dimitri
• 16:49   Re: Any better plan for this query?.. Tom Lane
• 17:54   Re: Any better plan for this query?.. Alvaro Herrera
• 18:53   Re: Any better plan for this query?.. Simon Riggs
• 21:01   Re: Any better plan for this query?.. Simon Riggs
• 23:21   Re: Any better plan for this query?.. Dimitri Fontaine
• 23:24   Re: Any better plan for this query?.. Scott Carey
• 23:27   Re: Any better plan for this query?.. Joshua D. Drake
• 23:35   Re: Any better plan for this query?.. Robert Haas
• 23:36   Re: Query planner making bad decisions Rafael Martinez
• 23:36   AMD Shanghai versus Intel Nehalem Scott Marlowe
• 23:49   Re: Any better plan for this query?.. Robert Haas
• 23:51   increase index performance Thomas Finneid
• 23:55   Re: Any better plan for this query?.. Alvaro Herrera
• 23:59   Re: Any better plan for this query?.. Greg Stark

13 May 2009

• 00:06   superlative missuse Angel Alvarez
• 00:12   Re: superlative missuse David Wilson
• 00:40   Re: Any better plan for this query?.. Joshua D. Drake
• 00:50   Re: Any better plan for this query?.. Aidan Van Dyk
• 01:45   Re: increase index performance Greg Smith
• 02:06   Re: AMD Shanghai versus Intel Nehalem Greg Smith
• 02:18   Re: Any better plan for this query?.. Stephen Frost
• 02:28   Re: AMD Shanghai versus Intel Nehalem Scott Marlowe
• 02:55   Re: Any better plan for this query?.. Robert Haas
• 03:09   Re: AMD Shanghai versus Intel Nehalem Scott Carey
• 03:24   Re: Any better plan for this query?.. Robert Haas
• 03:26   Re: Any better plan for this query?.. Glenn Maynard
• 03:59   Re: AMD Shanghai versus Intel Nehalem Scott Marlowe
• 07:51   raid setup for db Thomas Finneid
• 07:57   Re: increase index performance Thomas Finneid
• 08:28   Re: raid setup for db Scott Marlowe
• 08:31   Re: AMD Shanghai versus Intel Nehalem Scott Marlowe
• 08:33   Re: AMD Shanghai versus Intel Nehalem Arjen van der Meijden
• 08:44   Re: raid setup for db Rafael Martinez
• 09:50   Re: raid setup for db Thomas Finneid
• 10:02   Re: Any better plan for this query?.. Dimitri
• 10:03   Re: Timestamp index not used in some cases Евгений Василев
• 10:22   Re: Any better plan for this query?.. Dimitri
• 10:29   Re: Any better plan for this query?.. Dimitri
• 10:48   Re: Any better plan for this query?.. Dimitri
• 10:53   Re: increase index performance Matthew Wakeling
• 14:20   Re: PostgreSQL with PostGIS on embedded hardware Stefan Kaltenbrunner
• 14:45   Re: Any better plan for this query?.. Robert Haas
• 14:53   Re: Any better plan for this query?.. Kevin Grittner
• 15:04   Re: PostgreSQL with PostGIS on embedded hardware Greg Stark
• 16:16   Re: Any better plan for this query?.. Dimitri
• 16:42   Re: Any better plan for this query?.. Scott Carey
• 16:58   Re: AMD Shanghai versus Intel Nehalem Scott Carey
• 16:59   Re: superlative missuse Chris Browne
• 17:06   Re: Any better plan for this query?.. Kevin Grittner
• 17:08   Re: superlative missuse Tom Lane
• 18:44   Re: superlative missuse Angel Alvarez
• 18:47   Re: AMD Shanghai versus Intel Nehalem Scott Carey
• 18:59   Re: AMD Shanghai versus Intel Nehalem Scott Carey
• 19:45   Re: increase index performance Thomas Finneid
• 21:23   Re: Any better plan for this query?.. Dimitri Fontaine

14 May 2009

• 06:21   Re: AMD Shanghai versus Intel Nehalem Arjen van der Meijden
• 06:27   Re: increase index performance Ow Mun Heng
• 06:52   Re: AMD Shanghai versus Intel Nehalem Greg Smith
• 10:20   Re: increase index performance Matthew Wakeling
• 11:54   Re: increase index performance Ow Mun Heng
• 14:37   UNION ALL and sequential scans Brad Jorsch
• 14:52   Re: UNION ALL and sequential scans Tom Lane
• 15:10   Re: UNION ALL and sequential scans Mathieu De Zutter
• 15:22   Re: UNION ALL and sequential scans Tom Lane
• 17:01   Re: AMD Shanghai versus Intel Nehalem Scott Carey
• 17:03   Re: Any better plan for this query?.. Simon Riggs
• 17:10   Re: AMD Shanghai versus Intel Nehalem Scott Carey
• 18:25   Re: Any better plan for this query?.. Dimitri
• 18:28   Re: Any better plan for this query?.. Dimitri
• 18:34   Re: Any better plan for this query?.. Dimitri

15 May 2009

• 01:21   Re: superlative missuse David Wilson
• 02:21   Re: superlative missuse Craig James

18 May 2009

• 15:07   Re: Any better plan for this query?.. Simon Riggs
• 15:09   Re: Any better plan for this query?.. Simon Riggs
• 18:01   Re: Any better plan for this query?.. Dimitri
• 19:25   Re: Any better plan for this query?.. Simon Riggs
• 19:37   Re: Any better plan for this query?.. Scott Carey
• 20:44   Re: Any better plan for this query?.. Dave Dutcher
• 22:32   Re: Any better plan for this query?.. Dimitri
• 22:32   Re: Any better plan for this query?.. Dimitri
• 22:33   Re: Any better plan for this query?.. Dimitri
• 23:10   Re: Any better plan for this query?.. Tom Lane

19 May 2009

• 01:01   Re: Any better plan for this query?.. Scott Carey
• 07:24   Re: Any better plan for this query?.. Simon Riggs
• 10:30   Re: Any better plan for this query?.. Dimitri
• 10:46   Re: Any better plan for this query?.. Dimitri
• 10:52   Re: Any better plan for this query?.. Dimitri
• 10:55   Re: Any better plan for this query?.. Simon Riggs
• 11:18   Re: Any better plan for this query?.. Matthew Wakeling
• 11:34   Re: Any better plan for this query?.. Simon Riggs
• 11:39   Re: Any better plan for this query?.. Simon Riggs
• 12:00   Re: Any better plan for this query?.. Dimitri
• 12:02   Re: Any better plan for this query?.. Matthew Wakeling
• 13:32   Re: Any better plan for this query?.. Tom Lane
• 13:33   Re: Any better plan for this query?.. Simon Riggs
• 13:35   Re: Any better plan for this query?.. Merlin Moncure
• 14:01   Re: Any better plan for this query?.. Robert Haas
• 14:59   Re: Any better plan for this query?.. Dimitri
• 16:00   Re: Any better plan for this query?.. Dimitri
• 16:10   Re: Any better plan for this query?.. Simon Riggs
• 16:20   Re: Any better plan for this query?.. Simon Riggs
• 16:38   Re: Any better plan for this query?.. Scott Carey
• 17:13   Re: Any better plan for this query?.. Scott Carey
• 17:38   Re: Any better plan for this query?.. Merlin Moncure
• 18:59   Re: Any better plan for this query?.. Dimitri
• 19:15   Re: Any better plan for this query?.. Dimitri
• 21:48   Re: Any better plan for this query?.. Merlin Moncure
• 22:49   Re: Any better plan for this query?.. Tom Lane

20 May 2009

• 04:01   Re: Any better plan for this query?.. Robert Haas
• 08:09   Re: Any better plan for this query?.. Simon Riggs
• 11:17   Re: Any better plan for this query?.. Robert Haas
• 11:50   Re: Any better plan for this query?.. Simon Riggs
• 16:22   postgresql.conf suggestions? Kobby Dapaah

21 May 2009

• 03:09   Re: postgresql.conf suggestions? Robert Haas
• 05:47   Re: postgresql.conf suggestions? Greg Smith
• 11:17   PQisBusy behaving strangely Richard Yen
• 11:52   query planner uses sequencial scan instead of index scan Daniel Ferreira
• 12:54   raid10 hard disk choice Linos
• 13:15   Re: raid10 hard disk choice Matthew Wakeling
• 14:25   Re: raid10 hard disk choice Merlin Moncure
• 14:44   Re: raid10 hard disk choice Robert Schnabel
• 15:41   Re: query planner uses sequencial scan instead of index scan Tom Lane
• 15:58   Re: raid10 hard disk choice Joshua D. Drake
• 16:39   Re: raid10 hard disk choice Scott Marlowe
• 17:18   Re: raid10 hard disk choice Craig James
• 20:34   Re: raid10 hard disk choice Robert Haas
• 21:41   Re: raid10 hard disk choice Scott Marlowe
• 22:05   Re: raid10 hard disk choice Scott Carey
• 22:05   Re: raid10 hard disk choice Robert Haas

22 May 2009

• 02:14   Re: raid10 hard disk choice Scott Carey
• 06:59   Re: raid10 hard disk choice Greg Smith
• 07:08   Re: raid10 hard disk choice Greg Smith
• 09:46   Re: raid10 hard disk choice Linos
• 13:38   Re: raid10 hard disk choice Robert Schnabel
• 15:08   Re: raid10 hard disk choice Greg Smith
• 16:06   Re: raid10 hard disk choice Scott Marlowe
• 16:40   Re: raid10 hard disk choice Greg Smith
• 17:25   Re: raid10 hard disk choice Robert Schnabel
• 20:14   Re: Bad Plan for Questionnaire-Type Query David Blewett

23 May 2009

• 00:13   Re: Full statement logging problematic on larger machines? Frank Joerdens

24 May 2009

• 18:42   Re: Bad Plan for Questionnaire-Type Query Tom Lane
• 20:06   Problems with autovacuum Łukasz Jagiełło

25 May 2009

• 13:55   Putting tables or indexes in SSD or RAM: avoiding double caching? Shaul Dar
• 15:22   Re: Bad Plan for Questionnaire-Type Query David Blewett
• 15:40   Re: Problems with autovacuum Scott Marlowe
• 15:50   Re: Problems with autovacuum Grzegorz Jaśkiewicz
• 16:15   Re: Problems with autovacuum Scott Marlowe
• 18:31   Re: Problems with autovacuum Łukasz Jagiełło
• 18:43   Re: Problems with autovacuum Łukasz Jagiełło
• 18:55   Re: Problems with autovacuum Tom Lane
• 19:16   Re: Problems with autovacuum Łukasz Jagiełło
• 21:46   Re: Problems with autovacuum Grzegorz Jaśkiewicz

26 May 2009

• 16:00   Re: Putting tables or indexes in SSD or RAM: avoiding double caching? Kenny Gorman
• 18:20   Re: Problems with autovacuum Alvaro Herrera
• 18:28   Re: Problems with autovacuum Tom Lane
• 18:42   Re: Problems with autovacuum Alvaro Herrera
• 18:42   Re: Problems with autovacuum Łukasz Jagiełło
• 19:01   Re: Problems with autovacuum Tom Lane
• 21:51   Hosted servers with good DB disk performance? Greg Smith
• 22:28   Re: Hosted servers with good DB disk performance? Craig James
• 22:50   Re: Hosted servers with good DB disk performance? Marcin Stępnicki
• 22:53   Re: Hosted servers with good DB disk performance? Jerry Champlin
• 23:00   Re: Hosted servers with good DB disk performance? Joshua D. Drake
• 23:13   Re: Problems with autovacuum Alvaro Herrera
• 23:27   Re: Problems with autovacuum Tom Lane
• 23:52   Re: Problems with autovacuum Alvaro Herrera
• 23:58   Re: Hosted servers with good DB disk performance? Dave Page
• 23:59   Re: Problems with autovacuum Tom Lane

27 May 2009

• 01:17   Re: Hosted servers with good DB disk performance? Greg Smith
• 01:26   Re: Hosted servers with good DB disk performance? Josh Berkus
• 01:41   Re: Hosted servers with good DB disk performance? Scott Carey
• 01:52   Re: Hosted servers with good DB disk performance? Scott Marlowe
• 01:57   Re: Problems with autovacuum Scott Marlowe
• 02:27   Re: Hosted servers with good DB disk performance? Scott Carey
• 02:31   Re: Hosted servers with good DB disk performance? Scott Carey
• 02:35   Re: Hosted servers with good DB disk performance? Scott Marlowe
• 03:24   Re: Hosted servers with good DB disk performance? Greg Smith
• 04:05   Re: Hosted servers with good DB disk performance? Ron Mayer
• 04:15   Re: Hosted servers with good DB disk performance? Erik Aronesty
• 05:20   Re: Hosted servers with good DB disk performance? Alex Adriaanse
• 06:49   Bytea updation ramasubramanian
• 06:49    ramasubramanian
• 09:32   Re: Hosted servers with good DB disk performance? Dimitri Fontaine
• 11:24   Re: Bytea updation Albe Laurenz
• 12:05   L Thomas Kellerer
• 13:24   running bonnie++ Alan McKay
• 14:21   Re: running bonnie++ Glyn Astill
• 14:26   Re: Hosted servers with good DB disk performance? Joshua D. Drake
• 15:17   Improve Query Zach Calvert
• 15:25   Re: Improve Query Grzegorz Jaśkiewicz
• 15:42   Re: Hosted servers with good DB disk performance? David Wall
• 16:01   Re: running bonnie++ Greg Smith
• 16:02   Re: Hosted servers with good DB disk performance? Scott Mead
• 16:11   Re: Improve Query Nikolas Everett
• 16:25   Re: Improve Query Zach Calvert
• 16:32   Re: Improve Query Grzegorz Jaśkiewicz
• 16:42   Re: Improve Query Zach Calvert
• 17:10   Re: Improve Query Heikki Linnakangas
• 17:57   Postgres Clustering Alan McKay
• 18:25   Re: Postgres Clustering Thomas Kellerer
• 18:39   Re: Postgres Clustering Scott Mead
• 18:43   Re: Postgres Clustering Daniel van Ham Colchete
• 18:57   Re: Postgres Clustering Eddy Ernesto Baños Fernández
• 19:54   Re: Postgres Clustering Dimitri Fontaine
• 19:58   Re: Postgres Clustering Alan McKay

28 May 2009

• 12:54   Storing sensor data Ivan Voras
• 13:31   Re: Storing sensor data Heikki Linnakangas
• 13:38   Re: Storing sensor data Nikolas Everett
• 13:40   Re: Storing sensor data Alexander Staubo
• 14:56   Re: Storing sensor data Ivan Voras
• 14:58   Re: Storing sensor data Ivan Voras
• 15:01   Re: Storing sensor data Kenneth Marshall
• 15:14   Re: Storing sensor data Ivan Voras
• 15:24   Re: Storing sensor data Ivan Voras
• 15:35   Re: Storing sensor data Alexander Staubo
• 15:47   Re: Storing sensor data Grzegorz Jaśkiewicz
• 16:15   Continuent (was: Postgres Clustering) Alan McKay
• 17:12   Re: Storing sensor data Kenneth Marshall
• 18:51   Scalability in postgres Fabrix
• 18:56   Re: Storing sensor data Greg Jaman
• 19:44   Re: Storing sensor data Greg Jaman
• 20:12   Re: Scalability in postgres David Rees
• 20:22   Re: Scalability in postgres Scott Marlowe
• 20:53   Re: Scalability in postgres Fabrix
• 21:00   Re: Scalability in postgres Scott Mead
• 21:11   Re: Scalability in postgres Scott Marlowe
• 21:28   Re: Scalability in postgres Fabrix
• 22:13   Re: Scalability in postgres Fabrix
• 22:59   Unexpected query plan results Anne Rosset

29 May 2009

• 00:26   Re: Continuent (was: Postgres Clustering) Flavio Henrique Araque Gurgel
• 00:35   Re: Scalability in postgres Flavio Henrique Araque Gurgel
• 01:04   Re: Scalability in postgres Fabrix
• 01:16   Re: Scalability in postgres Scott Marlowe
• 01:24   Re: Scalability in postgres Flavio Henrique Araque Gurgel
• 01:55   Re: Scalability in postgres Greg Smith
• 10:45   Re: Scalability in postgres Grzegorz Jaśkiewicz
• 12:10   Re: Scalability in postgres Scott Marlowe
• 12:11   Re: Scalability in postgres Scott Marlowe
• 12:13   Re: Scalability in postgres Grzegorz Jaśkiewicz
• 12:38   Re: Scalability in postgres Scott Marlowe
• 12:41   Re: Scalability in postgres Grzegorz Jaśkiewicz
• 12:57   Re: Scalability in postgres Scott Marlowe
• 13:07   Re: Scalability in postgres Grzegorz Jaśkiewicz
• 13:21   Re: Scalability in postgres Scott Marlowe
• 15:55   Re: Unexpected query plan results Dave Dutcher
• 16:05   Re: Unexpected query plan results Anne Rosset
• 17:30   Re: Unexpected query plan results Dave Dutcher
• 17:38   Re: Scalability in postgres Greg Smith
• 17:49   Re: Scalability in postgres Fabrix
• 18:17   Re: Scalability in postgres Greg Smith
• 18:20   Re: Scalability in postgres Scott Mead
• 18:34   Re: Scalability in postgres Scott Marlowe
• 19:14   Re: Unexpected query plan results Scott Mead
• 19:46   Re: Scalability in postgres Fabrix
• 19:50   Re: Scalability in postgres Scott Mead
• 21:32   Re: Unexpected query plan results Anne Rosset
• 21:32   Re: Unexpected query plan results Robert Haas
• 21:34   Re: Unexpected query plan results Robert Haas
• 21:57   Re: Unexpected query plan results Anne Rosset
• 22:15   Re: Unexpected query plan results Robert Haas
• 23:56   autovacuum hung? Brian Cox

30 May 2009

• 00:02   Re: autovacuum hung? Alvaro Herrera
• 00:05   Re: autovacuum hung? Brian Cox
• 00:48   Re: Scalability in postgres Scott Carey
• 15:58   Re: autovacuum hung? Tom Lane

31 May 2009

• 03:42   Re: Scalability in postgres Greg Smith
• 09:30   Re: Scalability in postgres Scott Marlowe
• 09:59   degenerate performance on one server of 3 Erik Aronesty
• 14:52   Re: degenerate performance on one server of 3 Tom Lane
• 16:37   Re: Scalability in postgres Fabrix
• 17:28   Re: autovacuum hung? Brian Cox
• 17:32   Re: autovacuum hung? Tom Lane
• 19:09   Re: autovacuum hung? Brian Cox
• 19:34   Re: autovacuum hung? Tom Lane
• 20:45   Re: autovacuum hung? Brian Cox
• 21:14   Re: autovacuum hung? Tom Lane
• 21:15   Re: autovacuum hung? Tom Lane