Mailing lists [pgsql-performance]

1 May 2008

• 00:56   Re: Understanding histograms Gregory Stark
• 04:26   Please ignore ... Marc G. Fournier
• 04:41   Re: Understanding histograms Tom Lane
• 05:24   Re: Please ignore ... D'Arcy J.M. Cain
• 06:23   Re: Please ignore ... Justin
• 06:55   Re: Please ignore ... Greg Smith
• 07:35   Re: Please ignore ... Tino Wildenhain
• 09:34   Re: Postgres replication Fujii Masao
• 13:12   Re: Please ignore ... D'Arcy J.M. Cain
• 14:22   Re: Benchmarks WAS: Sun Talks about MySQL Jignesh K. Shah

2 May 2008

• 07:31   Pros and Cons of 8.3.1 Gauri Kanekar
• 07:51   Re: Pros and Cons of 8.3.1 Claus Guttesen
• 14:10   Re: Vacuum statistics chirag.dave@gmail.com
• 14:29   Re: Please ignore ... Alvaro Herrera
• 16:13   Re: Pros and Cons of 8.3.1 Justin
• 16:31   Re: Pros and Cons of 8.3.1 Joshua D. Drake
• 16:36   Re: Pros and Cons of 8.3.1 Kevin Grittner
• 16:46   Re: Pros and Cons of 8.3.1 Kevin Grittner
• 16:54   Re: Pros and Cons of 8.3.1 Kevin Grittner
• 19:24   two memory-consuming postgres processes Alexy Khrabrov
• 19:30   Re: two memory-consuming postgres processes Scott Marlowe
• 19:38   Re: two memory-consuming postgres processes Alexy Khrabrov
• 19:54   Re: two memory-consuming postgres processes Scott Marlowe
• 20:13   Re: two memory-consuming postgres processes Tom Lane
• 20:22   Re: two memory-consuming postgres processes Greg Smith
• 20:27   Re: two memory-consuming postgres processes Alexy Khrabrov
• 20:28   Re: two memory-consuming postgres processes Alexy Khrabrov
• 20:35   Re: two memory-consuming postgres processes Alexy Khrabrov
• 20:40   Re: two memory-consuming postgres processes Scott Marlowe
• 20:51   Re: two memory-consuming postgres processes Alexy Khrabrov
• 21:02   Re: two memory-consuming postgres processes Craig James
• 21:10   Re: two memory-consuming postgres processes Alexy Khrabrov
• 21:23   Re: two memory-consuming postgres processes Greg Smith
• 21:25   Re: two memory-consuming postgres processes PFC
• 21:30   Very slow INFORMATION_SCHEMA Ernesto
• 21:30   Re: two memory-consuming postgres processes Alexy Khrabrov
• 21:44   Re: two memory-consuming postgres processes Kevin Grittner
• 22:21   Re: Very slow INFORMATION_SCHEMA Tom Lane
• 22:29   Re: two memory-consuming postgres processes Kevin Grittner
• 22:31   Re: two memory-consuming postgres processes Alexy Khrabrov

3 May 2008

• 09:25   Re: two memory-consuming postgres processes Matthew Wakeling
• 15:07   Re: two memory-consuming postgres processes Merlin Moncure

4 May 2008

• 02:15   Re: Vacuum statistics Francisco Reyes
• 04:59   Re: Vacuum statistics Mark Kirkwood
• 11:29   Re: pgPool query cache Hannes Dorbath
• 12:59   Fastest way / best practice to calculate "next birthdays" Hannes Dorbath
• 16:11   Re: Fastest way / best practice to calculate "next birthdays" Joshua D. Drake
• 17:59   Re: Fastest way / best practice to calculate "next birthdays" Hannes Dorbath
• 19:05   Re: Fastest way / best practice to calculate "next birthdays" Zoltan Boszormenyi

5 May 2008

• 06:24   Re: Fastest way / best practice to calculate "next birthdays" Shane Ambler
• 11:39   Re: Very slow INFORMATION_SCHEMA Mario Weilguni
• 15:00   Backup causing poor performance - suggestions Campbell, Lance
• 15:05   Re: Backup causing poor performance - suggestions Scott Marlowe
• 15:11   Re: Backup causing poor performance - suggestions Campbell, Lance
• 15:54   Re: Backup causing poor performance - suggestions Scott Marlowe
• 16:10   Re: Backup causing poor performance - suggestions Craig James
• 17:06   Re: Backup causing poor performance - suggestions Scott Marlowe
• 17:42   Re: Backup causing poor performance - suggestions Simon Riggs
• 19:44   Re: Backup causing poor performance - suggestions Scott Marlowe
• 20:04   Re: Backup causing poor performance - suggestions Greg Smith
• 20:11   Re: Backup causing poor performance - suggestions Greg Smith
• 22:04   Re: Backup causing poor performance - suggestions Scott Marlowe
• 23:33   RAID 10 Benchmark with different I/O schedulers (was: Performance increase with elevator=deadline) Craig James

6 May 2008

• 00:56   Re: Very slow INFORMATION_SCHEMA Tom Lane
• 01:03   need to speed up query Justin
• 03:16   Re: RAID 10 Benchmark with different I/O schedulers (was: Performance increase with elevator=deadline) Scott Marlowe
• 03:27   Re: need to speed up query Scott Marlowe
• 03:59   Re: RAID 10 Benchmark with different I/O schedulers (was: Performance increase with elevator=deadline) Greg Smith
• 04:41   Re: need to speed up query Gregory Williamson
• 05:37   Re: need to speed up query Justin
• 05:48   Re: need to speed up query Justin
• 06:57   Re: need to speed up query PFC
• 08:39   plan difference between set-returning function with ROWS within IN() and a plain join Frank van Vugt
• 09:47   Re: plan difference between set-returning function with ROWS within IN() and a plain join PFC
• 11:19   Seqscan problem Vlad Arkhipov
• 11:55   Re: plan difference between set-returning function with ROWS within IN() and a plain join Frank van Vugt
• 12:26   Re: RAID 10 Benchmark with different I/O schedulers (was: Performance increase with elevator=deadline) Jeff
• 13:22   Re: need to speed up query Justin
• 14:17   Re: plan difference between set-returning function with ROWS within IN() and a plain join Tom Lane
• 14:22   Re: Seqscan problem Tom Lane
• 15:27   Re: plan difference between set-returning function with ROWS within IN() and a plain join Frank van Vugt
• 15:33   multiple joins + Order by + LIMIT query performance issue Antoine Baudoux
• 15:38   Re: multiple joins + Order by + LIMIT query performance issue Guillaume Smet
• 15:45   What constitutes a complex query Justin
• 16:27   Re: What constitutes a complex query Craig James
• 16:36   Re: need to speed up query PFC
• 16:41   Re: What constitutes a complex query Scott Marlowe
• 16:42   Re: multiple joins + Order by + LIMIT query performance issue Antoine Baudoux
• 16:49   Re: multiple joins + Order by + LIMIT query performance issue Shaun Thomas
• 16:50   Re: need to speed up query Shaun Thomas
• 16:56   Re: What constitutes a complex query Steve Atkins
• 16:58   Re: What constitutes a complex query Richard Broersma
• 16:59   Possible Redundancy/Performance Solution Dennis Muhlestein
• 17:22   Re: need to speed up query Justin
• 17:23   Re: What constitutes a complex query Justin
• 17:24   Re: multiple joins + Order by + LIMIT query performance issue Antoine Baudoux
• 17:38   Re: What constitutes a complex query Scott Marlowe
• 17:39   Re: Possible Redundancy/Performance Solution Greg Smith
• 17:42   Re: need to speed up query Justin
• 17:59   Re: multiple joins + Order by + LIMIT query performance issue Tom Lane
• 18:04   Re: multiple joins + Order by + LIMIT query performance issue Heikki Linnakangas
• 18:07   Re: multiple joins + Order by + LIMIT query performance issue Heikki Linnakangas
• 18:14   Re: multiple joins + Order by + LIMIT query performance issue Shaun Thomas
• 18:24   Re: multiple joins + Order by + LIMIT query performance issue Shaun Thomas
• 18:30   Re: RAID 10 Benchmark with different I/O schedulers Craig James
• 18:59   Re: Possible Redundancy/Performance Solution Dennis Muhlestein
• 20:21   Re: RAID 10 Benchmark with different I/O schedulers Greg Smith
• 20:35   Re: Possible Redundancy/Performance Solution Greg Smith
• 20:44   Re: RAID 10 Benchmark with different I/O schedulers Craig James
• 21:23   pgfouine - commit details? Josh Cole
• 21:59   Re: Possible Redundancy/Performance Solution Dennis Muhlestein

7 May 2008

• 00:32   Re: pgfouine - commit details? Guillaume Smet
• 00:48   Re: Seqscan problem Vlad Arkhipov
• 01:58   Re: Possible Redundancy/Performance Solution Scott Marlowe
• 02:37   Re: Possible Redundancy/Performance Solution Greg Smith
• 05:37   Re: pgfouine - commit details? Josh Cole
• 07:24   Re: multiple joins + Order by + LIMIT query performance issue Antoine Baudoux
• 07:33   Re: RAID 10 Benchmark with different I/O schedulers Albe Laurenz *EXTERN*
• 10:42   Re: multiple joins + Order by + LIMIT query performance issue Matthew Wakeling
• 10:46   Re: RAID 10 Benchmark with different I/O schedulers Matthew Wakeling
• 16:00   Re: Possible Redundancy/Performance Solution Dennis Muhlestein
• 16:28   Query Optimization with Kruskal’s Algorithm Tarcizio Bini
• 20:09   Re: Query Optimization with Kruskal’s Algorithm Alexander Staubo

8 May 2008

• 07:48   Re: [GENERAL] Ubuntu question Justin
• 07:50   Re: [GENERAL] Ubuntu question Justin
• 16:53   Creating a foreign key Campbell, Lance
• 16:59   Re: Creating a foreign key Joshua D. Drake
• 17:19   Re: Creating a foreign key Shaun Thomas
• 18:13   Re: Creating a foreign key Campbell, Lance
• 19:30   Creating indexes Rauan Maemirov
• 20:22   Re: Creating indexes Alan Hodgson
• 20:24   Re: Creating indexes Asche
• 20:24   Re: Creating a foreign key PFC
• 20:24   Re: Creating indexes PFC

9 May 2008

• 06:00   Re: Creating indexes Rauan Maemirov
• 07:19   Re: multiple joins + Order by + LIMIT query performance issue Antoine Baudoux
• 07:53   Re: multiple joins + Order by + LIMIT query performance issue Scott Marlowe
• 08:21   "append" takes a lot of time in a query Frank Dekervel
• 14:12   Re: "append" takes a lot of time in a query Tom Lane

10 May 2008

• 11:42   Re: plan difference between set-returning function with ROWS within IN() and a plain join Merlin Moncure
• 18:00   Re: Query Optimization with Kruskal’s Algorithm Rauan Maemirov
• 20:27   Re: Re: Query Optimization with Kruskal’s Algorithm Jonah H. Harris
• 21:12   Re: Re: Re: Query Optimization with Kruskal’s Algorithm  Tom Lane
• 21:17   Re: Re: Re: Query Optimization with Kruskal’s Algorithm Jonah H. Harris

11 May 2008

• 00:37   Re: Re: Re: Re: Query Optimization with Kruskal’s Algorithm  Tom Lane
• 04:53   Re: Re: Query Optimization with Kruskal’s Algorithm Michael Glaesemann

12 May 2008

• 16:19   Partitioning: INSERT 0 0 but want INSERT 0 1 Nikolas Everett
• 22:28   Re: Partitioning: INSERT 0 0 but want INSERT 0 1 Neil Peter Braggio

13 May 2008

• 02:04   RAID controllers for Postgresql on large setups Francisco Reyes
• 02:11   Re: RAID controllers for Postgresql on large setups Joshua D. Drake
• 03:31   Re: RAID controllers for Postgresql on large setups Francisco Reyes
• 03:57   Re: Partitioning: INSERT 0 0 but want INSERT 0 1 Nikolas Everett
• 04:10   Re: RAID controllers for Postgresql on large setups Chris Ruprecht
• 04:40   Re: RAID controllers for Postgresql on large setups Joshua D. Drake
• 04:42   Re: RAID controllers for Postgresql on large setups Joshua D. Drake
• 05:59   Re: RAID controllers for Postgresql on large setups Greg Smith
• 06:02   Installation Steps to migrate to Postgres 8.3.1 Gauri Kanekar
• 06:49   Re: Installation Steps to migrate to Postgres 8.3.1 Claus Guttesen
• 08:17   Re: RAID controllers for Postgresql on large setups Scott Marlowe
• 08:25   Re: Installation Steps to migrate to Postgres 8.3.1 Scott Marlowe
• 09:54   Re: RAID controllers for Postgresql on large setups PFC
• 12:01   Re: RAID controllers for Postgresql on large setups Francisco Reyes
• 12:10   Re: RAID controllers for Postgresql on large setups Merlin Moncure
• 12:15   Re: Installation Steps to migrate to Postgres 8.3.1 Knight, Doug
• 14:50   Re: Installation Steps to migrate to Postgres 8.3.1 Scott Marlowe
• 15:08   Re: RAID controllers for Postgresql on large setups Vivek Khera
• 15:09   Re: RAID controllers for Postgresql on large setups Vivek Khera
• 16:57   Problem with 11 M records table idc danny
• 17:05   Re: Problem with 11 M records table Bill Moran
• 17:09   Re: Problem with 11 M records table salman
• 17:17   Re: Problem with 11 M records table Craig James
• 17:57   Re: Problem with 11 M records table Craig James
• 18:02   Re: Problem with 11 M records table Scott Marlowe
• 20:09   Re: RAID controllers for Postgresql on large setups James Mansion
• 20:40   Re: RAID controllers for Postgresql on large setups PFC

14 May 2008

• 04:53   can I move sort to first outer join ? fernando castano
• 06:09   Re: Problem with 11 M records table Ramasubramanian G
• 06:11   Regexps - never completing join. Rusty Conover
• 07:08   Re: Regexps - never completing join. Rusty Conover
• 09:52   Re: can I move sort to first outer join ? PFC
• 10:07   postgres overall performance seems to degrade when large SELECT are requested Valentin Bogdanov
• 11:04   Re: postgres overall performance seems to degrade when large SELECT are requested PFC
• 15:37   Re: Regexps - never completing join. Rusty Conover
• 20:11   I/O on select count(*) Doug Eck
• 20:38   Re: I/O on select count(*) Merlin Moncure
• 21:23   Re: I/O on select count(*) Doug Eck
• 22:11   Re: I/O on select count(*) Kevin Grittner
• 22:35   poor row estimates with multi-column joins Robert Treat
• 22:38   Update performance degrades over time Subbiah Stalin-XCGF84

15 May 2008

• 01:40   Re: I/O on select count(*) Greg Smith
• 02:06   Re: I/O on select count(*) Alvaro Herrera
• 02:21   Re: I/O on select count(*) Greg Smith
• 02:38   Re: I/O on select count(*) Jan de Visser
• 02:41   Re: I/O on select count(*) Pavan Deolasee
• 02:53   Re: I/O on select count(*) Luke Lonergan
• 03:07   Re: I/O on select count(*) Greg Smith
• 03:14   Re: I/O on select count(*) Joshua D. Drake
• 06:14   Re: I/O on select count(*) Tino Wildenhain
• 07:54   Re: I/O on select count(*) Tom Lane
• 08:00   Re: I/O on select count(*) Tom Lane
• 10:40   which ext3 fs type should I use for postgresql Philippe Amelant
• 11:29   Re: which ext3 fs type should I use for postgresql Matthew Wakeling
• 12:15   Re: which ext3 fs type should I use for postgresql david@lang.hm
• 12:24   Re: which ext3 fs type should I use for postgresql Matthew Wakeling
• 12:40   Re: I/O on select count(*) Matthew Wakeling
• 12:54   Re: I/O on select count(*) Heikki Linnakangas
• 12:55   Re: I/O on select count(*) Matthew Wakeling
• 13:15   Re: I/O on select count(*) Jan de Visser
• 13:39   Re: I/O on select count(*) Matthew Wakeling
• 13:51   Re: I/O on select count(*) Ron Mayer
• 13:57   Re: Update performance degrades over time Jeffrey Baker
• 14:41   Re: I/O on select count(*) Alvaro Herrera
• 14:57   Re: I/O on select count(*) Tom Lane
• 14:59   Re: which ext3 fs type should I use for postgresql Craig James
• 15:08   Re: which ext3 fs type should I use for postgresql Guillaume Cottenceau
• 15:09   Re: I/O on select count(*) Heikki Linnakangas
• 15:17   Re: I/O on select count(*) Heikki Linnakangas
• 15:17   Re: I/O on select count(*) Matthew Wakeling
• 15:21   Re: which ext3 fs type should I use for postgresql Matthew Wakeling
• 15:32   Re: which ext3 fs type should I use for postgresql Guillaume Cottenceau
• 15:38   Re: which ext3 fs type should I use for postgresql Joshua D. Drake
• 15:49   Re: I/O on select count(*) Alvaro Herrera
• 15:52   Re: I/O on select count(*) Alvaro Herrera
• 15:56   Re: which ext3 fs type should I use for postgresql Guillaume Cottenceau
• 16:19   Re: I/O on select count(*) Tom Lane
• 16:28   Re: Update performance degrades over time Subbiah Stalin-XCGF84
• 16:53   Re: I/O on select count(*) Robert Lor
• 17:42   Re: I/O on select count(*) Tom Lane
• 19:27   Re: Update performance degrades over time Subbiah Stalin-XCGF84
• 21:21   Re: I/O on select count(*) Robert Lor
• 22:07   Re: I/O on select count(*) James Mansion
• 22:30   Re: I/O on select count(*) Gregory Stark
• 22:38   Re: I/O on select count(*) Kevin Grittner

16 May 2008

• 06:43   Join runs for > 10 hours and then fills up >1.3TB of disk space kevin kempter
• 08:08   Re: Join runs for > 10 hours and then fills up >1.3TB of disk space Claus Guttesen
• 08:08   Re: Join runs for > 10 hours and then fills up >1.3TB of disk space kevin kempter
• 08:10   Re: Join runs for > 10 hours and then fills up >1.3TB of disk space kevin kempter
• 08:18   Re: Join runs for > 10 hours and then fills up >1.3TB of disk space Simon Riggs
• 08:19   Re: Join runs for > 10 hours and then fills up >1.3TB of disk space Richard Huxton
• 08:27   Re: Join runs for > 10 hours and then fills up >1.3TB of disk space kevin kempter
• 08:32   Re: Join runs for > 10 hours and then fills up >1.3TB of disk space Richard Huxton
• 08:33   Re: Join runs for > 10 hours and then fills up >1.3TB of disk space Richard Huxton
• 08:47   Re: Join runs for > 10 hours and then fills up >1.3TB of disk space Luke Lonergan
• 08:50   Re: Join runs for > 10 hours and then fills up >1.3TB of disk space kevin kempter
• 09:52   Re: which ext3 fs type should I use for postgresql david@lang.hm
• 17:07   Re: which ext3 fs type should I use for postgresql Scott Marlowe
• 17:14   Re: which ext3 fs type should I use for postgresql Joshua D. Drake
• 17:56   very slow left join Ben
• 18:06   Re: I/O on select count(*) Greg Smith
• 18:09   Re: very slow left join Scott Marlowe
• 18:21   Re: very slow left join Ben
• 18:22   Re: I/O on select count(*) Simon Riggs
• 18:27   Re: very slow left join Scott Marlowe
• 18:43   Re: very slow left join Ben
• 19:25   Re: very slow left join Craig Ringer
• 20:15   Re: I/O on select count(*) Alvaro Herrera
• 20:35   Re: Regexps - never completing join. Scott Marlowe
• 21:01   Re: I/O on select count(*) Alvaro Herrera
• 21:03   Re: Please ignore ... Alvaro Herrera
• 21:37   Re: Regexps - never completing join. Rusty Conover
• 21:44   Re: Regexps - never completing join. Scott Marlowe

17 May 2008

• 02:45   Re: I/O on select count(*) Tom Lane
• 13:14   Re: I/O on select count(*) Jeremy Harris

18 May 2008

• 05:48   Re: I/O on select count(*) Greg Smith
• 16:25   Re: Strange behavior: pgbench and new Linux kernels Greg Smith

19 May 2008

• 12:32   Re: I/O on select count(*) Matthew Wakeling
• 14:54   Re: I/O on select count(*) Bruce Momjian
• 15:38   Re: I/O on select count(*) Tom Lane
• 15:47   Re: I/O on select count(*) Greg Smith
• 15:54   Re: I/O on select count(*) Tom Lane
• 17:09   Re: I/O on select count(*) PFC

20 May 2008

• 06:00   slow update kevin kempter
• 06:24   Re: slow update A. Kretschmer
• 11:52   Author Wanted Markus Feilner
• 12:32   Re: Author Wanted Bill Moran
• 17:47   Re: slow update Scott Marlowe
• 19:58   improving performance for a delete kevin kempter
• 20:03   Re: improving performance for a delete kevin kempter
• 20:47   Re: improving performance for a delete PFC

21 May 2008

• 05:52   Varchar pkey instead of integer Robins Tharakan
• 06:16   Re: Varchar pkey instead of integer Joshua D. Drake
• 06:34   Re: Varchar pkey instead of integer Craig Ringer
• 07:33   Re: Varchar pkey instead of integer Shane Ambler
• 08:02   Re: Varchar pkey instead of integer Craig Ringer
• 08:57   Re: Varchar pkey instead of integer J. Andrew Rogers
• 10:35   Posible planner improvement? Albert Cervera Areny
• 10:38   Re: "append" takes a lot of time in a query Frank Dekervel
• 10:48   Re: Posible planner improvement? Richard Huxton
• 11:11   Re: Posible planner improvement? Albert Cervera Areny
• 11:25   Re: Posible planner improvement? Mark Mielke
• 11:30   Re: Posible planner improvement? Albert Cervera Areny
• 11:37   Re: Posible planner improvement? Albert Cervera Areny
• 11:51   Re: Posible planner improvement? Luke Lonergan
• 13:09   Re: Posible planner improvement? Richard Huxton
• 14:20   "Big O" notation for postgres? H. Hall
• 14:29   Re: "Big O" notation for postgres? Jonah H. Harris
• 14:40   Re: "Big O" notation for postgres? Richard Huxton
• 16:12   Re: Posible planner improvement? PFC
• 16:20   Re: "Big O" notation for postgres? PFC
• 16:22   Re: Posible planner improvement? Albert Cervera Areny
• 18:44   Re: "append" takes a lot of time in a query Scott Marlowe
• 19:15   Re: "Big O" notation for postgres? H. Hall

22 May 2008

• 00:54   Re: Varchar pkey instead of integer Robins Tharakan
• 12:32   Index creation time and distribution Guillaume Smet
• 13:14   Re: Index creation time and distribution Tom Lane
• 13:38   Re: Index creation time and distribution Guillaume Smet
• 14:10   Re: Index creation time and distribution Matthew Wakeling
• 16:50   Re: Index creation time and distribution Scott Marlowe
• 18:35   Re: Index creation time and distribution Guillaume Smet
• 19:18   Re: Index creation time and distribution Tom Lane
• 21:52   Re: Index creation time and distribution Guillaume Smet
• 23:08   Re: "Big O" notation for postgres? Gregory Stark

23 May 2008

• 03:49   Re: I/O on select count(*) Luke Lonergan
• 09:01   join/from_collapse_limit and geqo_threshold default values Vlad Arkhipov
• 10:49   Quad Xeon or Quad Opteron? Andrzej Zawadzki
• 11:34   Re: Quad Xeon or Quad Opteron? Craig Ringer
• 12:22   Re: Quad Xeon or Quad Opteron? Adam Tauno Williams
• 12:36   Re: Quad Xeon or Quad Opteron? Knight, Doug
• 13:00   Re: Quad Xeon or Quad Opteron? Reid Thompson
• 13:28   index performance on large tables with update and insert Jessica Richard
• 15:15   IBM ServRAID-MR10M / LSI1078ROC advice Kevin Grittner
• 16:35   Re: index performance on large tables with update and insert Magnus Hagander

24 May 2008

• 16:39   Re: Quad Xeon or Quad Opteron? Andrzej Zawadzki
• 16:49   Re: Quad Xeon or Quad Opteron? Andrzej Zawadzki
• 18:50   Re: Creating large database of MD5 hash values Decibel!
• 18:51   Re: shared_buffers performance Decibel!
• 18:51   Re: Posible planner improvement? Decibel!
• 19:07   Re: I/O on select count(*) Decibel!
• 19:15   Re: I/O on select count(*) Decibel!
• 20:39   Re: Quad Xeon or Quad Opteron? Jeffrey Baker

26 May 2008

• 11:30   Re: Posible planner improvement? ITAGAKI Takahiro
• 13:03   Re: I/O on select count(*) Heikki Linnakangas
• 14:12   Symbolic Links to Tablespaces Campbell, Lance
• 15:00   Re: "Big O" notation for postgres? H. Hall
• 15:09   Re: Symbolic Links to Tablespaces Tom Lane
• 15:37   Re: I/O on select count(*) Tom Lane
• 17:10   Re: Symbolic Links to Tablespaces Campbell, Lance
• 17:32   Re: Symbolic Links to Tablespaces A. Kretschmer
• 18:26   Re: Symbolic Links to Tablespaces Heikki Linnakangas
• 19:19   Re: Symbolic Links to Tablespaces Tino Wildenhain
• 20:26   Re: Symbolic Links to Tablespaces Heikki Linnakangas
• 23:14   Re: RAID controllers for Postgresql on large setups Marinos Yannikos
• 23:32   Re: [GENERAL] select query takes 13 seconds to run with index mark
• 23:57   Re: [GENERAL] select query takes 13 seconds to run with index mark

27 May 2008

• 08:13   Re: [GENERAL] select query takes 13 seconds to run with index PFC
• 08:22   Re: [GENERAL] select query takes 13 seconds to run with index hubert depesz lubaczewski
• 14:47   Re: [GENERAL] select query takes 13 seconds to run with index mark
• 14:58   Re: [GENERAL] select query takes 13 seconds to run with index hubert depesz lubaczewski
• 19:56   Outer joins and equivalence Simon Riggs
• 20:52   Re: I/O on select count(*) Simon Riggs
• 21:44   Re: Outer joins and equivalence Tom Lane

28 May 2008

• 10:45   Re: Outer joins and equivalence Matthew Wakeling
• 13:37   Re: Outer joins and equivalence Simon Riggs
• 13:51   GEQO Benchmark tarcizioab@c3sl.ufpr.br
• 14:03   Re: GEQO Benchmark Tom Lane
• 16:13   Re: GEQO Benchmark Tarcizio Bini
• 16:50   Re: GEQO Benchmark Simon Riggs
• 17:55   Re: GEQO Benchmark Tarcizio Bini
• 23:37   Re: Creating large database of MD5 hash values Bruce Momjian
• 23:42   Re: Creating large database of MD5 hash values Tom Lane
• 23:56   2GB or not 2GB Josh Berkus

29 May 2008

• 00:07   Re: 2GB or not 2GB Steve Crawford
• 01:03   Re: 2GB or not 2GB Gregory Stark
• 01:19   Re: 2GB or not 2GB Greg Smith
• 02:54   Re: 2GB or not 2GB Jignesh K. Shah
• 03:02   Re: 2GB or not 2GB Jignesh K. Shah
• 09:37   IN() statement values order makes 2x performance hit Alexey Kupershtokh
• 09:40   Re: IN() statement values order makes 2x performance hit Oleg Bartunov
• 09:51   Re: IN() statement values order makes 2x performance hit Alexey Kupershtokh
• 15:44   Re: 2GB or not 2GB Joshua D. Drake
• 15:49   Adding "LIMIT 1" kills performance. Chris Shoemaker
• 16:53   Re: Adding "LIMIT 1" kills performance. Shane Ambler
• 17:23   OVERLAPS is slow Chris Browne
• 17:49   Re: Adding "LIMIT 1" kills performance. Chris Shoemaker
• 17:59   Re: Adding "LIMIT 1" kills performance. Tom Lane
• 19:50   Re: 2GB or not 2GB Magnus Hagander
• 22:10   ProcArrayLock (The Saga continues) Jignesh K. Shah

30 May 2008

• 00:28   Re: ProcArrayLock (The Saga continues) Gregory Stark

31 May 2008

• 04:24   Statistics issue Vlad Arkhipov
• 07:42   Re: 2GB or not 2GB Simon Riggs
• 15:51   Re: Statistics issue Tom Lane
• 18:53   Re: 2GB or not 2GB Josh Berkus
• 19:41   Re: 2GB or not 2GB Gregory Stark