Discussion of PostgreSQL's performance issues. Please see Guide to reporting problems and Slow Query Questions for some tips on how to write your performance question.
| Thread | Author | Time |
|---|---|---|
| A query become very slow after upgrade from 8.1.10 to 8.4.5 | Yaocl | 02:50 |
| Re: Insert performance with composite index | hubert depesz lubaczewski | 09:45 |
| Re: Insert performance with composite index | Cédric Villemain | 11:04 |
| Re: Insert performance with composite index | hubert depesz lubaczewski | 11:53 |
| Re: Insert performance with composite index | Divakar Singh | 12:51 |
| Array interface | Mladen Gogala | 19:46 |
| Re: Insert performance with composite index | Cédric Villemain | 20:32 |
| Array interface | Mladen Gogala | 21:18 |
| Test | Mladen Gogala | 21:21 |
| Array interface | Mladen Gogala | 21:32 |
| Re: [PERFORM] typoed column name, but postgres didn't grump | Kevin Grittner | 21:34 |
| Re: [PERFORM] typoed column name, but postgres didn't grump | Jon Nelson | 22:17 |
| Re: A query become very slow after upgrade from 8.1.10 to 8.4.5 | Tom Lane | 22:30 |
| Re: Array interface | Conor Walsh | 22:40 |
| Thread | Author | Time |
|---|---|---|
| Re: A query become very slow after upgrade from 8.1.10 to 8.4.5 | Yaocl | 01:47 |
| Re: Array interface | Mladen Gogala | 14:56 |
| Re: Test | Robert Gravsjö | 15:50 |
| Simple (hopefully) throughput question? | Nick Matheson | 15:52 |
| Bufer cache replacement LRU algorithm? | Mladen Gogala | 16:35 |
| Re: Bufer cache replacement LRU algorithm? | Kenneth Marshall | 16:52 |
| Re: Bufer cache replacement LRU algorithm? | Kevin Grittner | 17:09 |
| Re: Simple (hopefully) throughput question? | Heikki Linnakangas | 17:10 |
| Re: Simple (hopefully) throughput question? | Marti Raudsepp | 17:17 |
| Re: Simple (hopefully) throughput question? | Andy Colson | 17:40 |
| Thread | Author | Time |
|---|---|---|
| postmaster consuming /lots/ of memory with hash aggregate. why? | Jon Nelson | 00:26 |
| Re: postmaster consuming /lots/ of memory with hash aggregate. why? | Pierre C | 08:57 |
| Re: postmaster consuming /lots/ of memory with hash aggregate. why? | Jon Nelson | 18:37 |
| Thread | Author | Time |
|---|---|---|
| Re: Running PostgreSQL as fast as possible no matter the consequences | Craig Ringer | 00:21 |
| Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds | Robert Haas | 01:23 |
| questions regarding shared_buffers behavior | Mark Rostron | 20:33 |
| Re: questions regarding shared_buffers behavior | Greg Smith | 23:30 |
| Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? | Greg Smith | 23:35 |
| Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? | Andres Freund | 23:45 |
| Thread | Author | Time |
|---|---|---|
| out of memory problem | Till Kirchner | 10:39 |
| Re: out of memory problem | Tom Lane | 15:22 |
| Re: out of memory problem | Bob Lunney | 16:02 |
| anti-join chosen even when slower than old plan | Kevin Grittner | 21:18 |
| Huge overestimation in rows expected results in bad plan | bricklen | 21:26 |
| Re: Huge overestimation in rows expected results in bad plan | Andy Colson | 22:48 |
| Re: Huge overestimation in rows expected results in bad plan | bricklen | 22:59 |
| Re: anti-join chosen even when slower than old plan | Kevin Grittner | 23:07 |
| Re: anti-join chosen even when slower than old plan | Tom Lane | 23:17 |
| Re: anti-join chosen even when slower than old plan | Kevin Grittner | 23:24 |
| Re: Huge overestimation in rows expected results in bad plan | Tom Lane | 23:29 |
| Re: Huge overestimation in rows expected results in bad plan | bricklen | 23:39 |
| Re: Huge overestimation in rows expected results in bad plan | Tom Lane | 23:55 |
| Thread | Author | Time |
|---|---|---|
| Re: anti-join chosen even when slower than old plan | Tom Lane | 00:08 |
| Re: Huge overestimation in rows expected results in bad plan | bricklen | 00:10 |
| Re: anti-join chosen even when slower than old plan | Grzegorz Jaśkiewicz | 05:36 |
| Re: Array interface 📎 | Mark Kirkwood | 09:10 |
| Why dose the planner select one bad scan plan. | 静安寺 | 09:37 |
| Re: Array interface 📎 | Mark Kirkwood | 09:42 |
| Re: anti-join chosen even when slower than old plan | Kevin Grittner | 12:38 |
| Re: Why dose the planner select one bad scan plan. | tv | 12:48 |
| Re: anti-join chosen even when slower than old plan | Kevin Grittner | 15:15 |
| Re: anti-join chosen even when slower than old plan | Tom Lane | 15:33 |
| Re: anti-join chosen even when slower than old plan | Robert Haas | 22:07 |
| Re: anti-join chosen even when slower than old plan | Kevin Grittner | 22:43 |
| Re: anti-join chosen even when slower than old plan | Tom Lane | 23:07 |
| Thread | Author | Time |
|---|---|---|
| Re: postmaster consuming /lots/ of memory with hash aggregate. why? | Jon Nelson | 02:30 |
| Re: postmaster consuming /lots/ of memory with hash aggregate. why? | Pavel Stehule | 04:26 |
| Re: postmaster consuming /lots/ of memory with hash aggregate. why? | Jon Nelson | 04:33 |
| Re: postmaster consuming /lots/ of memory with hash aggregate. why? | Pavel Stehule | 04:38 |
| autovacuum blocks the operations of other manual vacuum | kuopo | 08:01 |
| Re: anti-join chosen even when slower than old plan | Cédric Villemain | 09:07 |
| Re: anti-join chosen even when slower than old plan | Cédric Villemain | 09:15 |
| Re: anti-join chosen even when slower than old plan | Vitalii Tymchyshyn | 10:10 |