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 |
---|---|---|
Re: 8.2 Autovacuum BUG ? | Pavan Teja | 04:46 |
PostgreSQL 10.1 partitions and indexes | Mariel Cherkassky | 10:30 |
dsa_allocate() faliure | Rick Otten | 16:19 |
Re: dsa_allocate() faliure | Tom Lane | 16:37 |
Re: dsa_allocate() faliure | Thomas Munro | 20:52 |
Re: dsa_allocate() faliure | Rick Otten | 21:35 |
Thread | Author | Time |
---|---|---|
Re: 8.2 Autovacuum BUG ? | pavan95 | 13:55 |
Re: SV: pgaudit and create postgis extension logs a lot inserts | Bruce Momjian | 15:26 |
Re: 8.2 Autovacuum BUG ? | Claudio Freire | 16:13 |
Thread | Author | Time |
---|---|---|
Nested Loops | Kumar, Virendra | 06:37 |
Re: Nested Loops | Laurenz Albe | 08:42 |
effective_io_concurrency on EBS/gp2 📎 | Vitaliy Garnashevich | 12:03 |
Re: effective_io_concurrency on EBS/gp2 | Rick Otten | 13:01 |
Re: effective_io_concurrency on EBS/gp2 | Vitaliy Garnashevich | 13:15 |
Re: effective_io_concurrency on EBS/gp2 | Pavel Stehule | 13:24 |
RE: effective_io_concurrency on EBS/gp2 | Gary Doades | 13:46 |
Re: effective_io_concurrency on EBS/gp2 | Vitaliy Garnashevich | 16:57 |
Re: effective_io_concurrency on EBS/gp2 | Claudio Freire | 19:34 |
Re: effective_io_concurrency on EBS/gp2 | Vitaliy Garnashevich | 20:29 |
Re: effective_io_concurrency on EBS/gp2 | Jeff Janes | 21:00 |
Thread | Author | Time |
---|---|---|
Re: effective_io_concurrency on EBS/gp2 📎 | hzzhangjiazhi | 02:21 |
Re: 8.2 Autovacuum BUG ? | pavan95 | 06:18 |
bad plan using nested loops | Johan Fredriksson | 10:42 |
Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used 📎 | Nandakumar M | 14:30 |
Re: bad plan using nested loops | Tom Lane | 15:00 |
Re: effective_io_concurrency on EBS/gp2 | Claudio Freire | 18:39 |
SV: bad plan using nested loops | Johan Fredriksson | 20:34 |
Thread | Author | Time |
---|---|---|
Re: SV: bad plan using nested loops | Johan Fredriksson | 09:02 |
Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used | Laurenz Albe | 09:36 |
Re: effective_io_concurrency on EBS/gp2 📎 | Vitaliy Garnashevich | 11:46 |
Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used | Nandakumar M | 14:04 |
Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used | Tom Lane | 15:00 |
Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used | Nandakumar M | 15:49 |
Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used | David G. Johnston | 15:58 |
Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used | Nandakumar M | 17:01 |
Re: [HACKERS] proposal: schema variables 📎 | Pavel Stehule | 22:06 |
Thread | Author | Time |
---|---|---|
Re: [HACKERS] proposal: schema variables 📎 | David G. Johnston | 00:48 |
Re: [HACKERS] proposal: schema variables | Pavel Stehule | 06:58 |
Re: effective_io_concurrency on EBS/gp2 📎 | Vitaliy Garnashevich | 23:05 |
Thread | Author | Time |
---|---|---|
Re: effective_io_concurrency on EBS/gp2 | Claudio Freire | 02:27 |
Re: effective_io_concurrency on EBS/gp2 | Vitaliy Garnashevich | 11:26 |
OT: Performance of VM | Thomas Güttler | 13:14 |
Re: OT: Performance of VM | Andreas Kretschmer | 13:26 |
Re: OT: Performance of VM | Andrew Kerber | 16:22 |
Re: OT: Performance of VM | Andreas Kretschmer | 16:33 |
Re: SV: bad plan using nested loops | Tomas Vondra | 19:15 |
Re: postgresql 10.1 wrong plan in when using partitions bug | Justin Pryzby | 19:19 |
Re: effective_io_concurrency on EBS/gp2 | Claudio Freire | 20:14 |
Thread | Author | Time |
---|---|---|
Details after Load Peak was: OT: Performance of VM | Thomas Güttler | 14:31 |
Re: Details after Load Peak was: OT: Performance of VM | Alan Hodgson | 15:30 |
Re: failing to use index on UNION of matviews (Re: postgresql 10.1 wrong plan in when using partitions bug) | Justin Pryzby | 18:18 |
Re: failing to use index on UNION of matviews (Re: postgresql 10.1 wrong plan in when using partitions bug) | Rick Otten | 20:02 |
Re: failing to use index on UNION of matviews (Re: postgresql 10.1 wrong plan in when using partitions bug) | Rick Otten | 20:03 |
Thread | Author | Time |
---|---|---|
Re: effective_io_concurrency on EBS/gp2 | Justin Pryzby | 05:42 |
Re: [HACKERS] proposal: schema variables 📎 | Pavel Stehule | 06:34 |
RE: pg_xlog unbounded growth | Alex Ignatov | 17:11 |
Thread | Author | Time |
---|---|---|
Re: failing to use index on UNION of matviews (Re: postgresql 10.1 wrong plan in when using partitions bug) | Rick Otten | 11:04 |
Re: effective_io_concurrency on EBS/gp2 📎 | Vitaliy Garnashevich | 16:05 |
Re: effective_io_concurrency on EBS/gp2 📎 | Vitaliy Garnashevich | 16:40 |
Thread | Author | Time |
---|---|---|
Same plans different performance? 📎 | Elias Panagiotidis | 11:56 |
Thread | Author | Time |
---|---|---|
Re: OT: Performance of VM | Robert Klemme | 11:20 |
Re: OT: Performance of VM | Andrew Kerber | 14:58 |
Thread | Author | Time |
---|---|---|
Efficiently searching for the most recent rows where a column matches any result from a different query | mkslaf | 13:28 |
Re: Efficiently searching for the most recent rows where a column matches any result from a different query | Hellmuth Vargas | 21:13 |
Re: Details after Load Peak was: OT: Performance of VM | Gunnar "Nick" Bluth | 21:15 |
Re: Details after Load Peak was: OT: Performance of VM | Micky Gough | 21:55 |
Thread | Author | Time |
---|---|---|
Re: OT: Performance of VM | Mark Kirkwood | 03:43 |
Thread | Author | Time |
---|---|---|
Re: Efficiently searching for the most recent rows where a column matches any result from a different query | mkslaf | 12:18 |
Thread | Author | Time |
---|---|---|
pgpool 2 rotate logs | Mariel Cherkassky | 15:19 |
Thread | Author | Time |
---|---|---|
Re: pgpool 2 rotate logs | Tatsuo Ishii | 01:03 |
Re: Efficiently searching for the most recent rows where a column matches any result from a different query | Nandakumar M | 10:04 |
Re: Efficiently searching for the most recent rows where a column matches any result from a different query | Nandakumar M | 10:10 |
Thread | Author | Time |
---|---|---|
blending fast and temp space volumes | Rick Otten | 15:53 |
Re: blending fast and temp space volumes | Tom Lane | 16:04 |
Re: blending fast and temp space volumes | Craig James | 19:22 |
Re: blending fast and temp space volumes | Peter Geoghegan | 19:50 |
Re: blending fast and temp space volumes | Claudio Freire | 20:07 |
Re: blending fast and temp space volumes | Peter Geoghegan | 20:09 |
Thread | Author | Time |
---|---|---|
Re: blending fast and temp space volumes | Claudio Freire | 11:30 |
Thread | Author | Time |
---|---|---|
need advice to tune postgresql | Darius Pėža | 14:42 |
Re: need advice to tune postgresql | MichaelDBA | 15:03 |
Re: effective_io_concurrency on EBS/gp2 | Rick Otten | 15:23 |
Re: need advice to tune postgresql | Laurenz Albe | 15:26 |
Re: effective_io_concurrency on EBS/gp2 | Vitaliy Garnashevich | 15:35 |
Performance | Daulat Ram | 19:29 |
Please help | Daulat Ram | 19:31 |
Re: Performance | Andreas Kretschmer | 21:20 |
Re: Please help | Andreas Kretschmer | 21:23 |
Updating large tables without dead tuples | ldh@laurent-hasson.com | 23:27 |
Thread | Author | Time |
---|---|---|
Re: Updating large tables without dead tuples | Stephen Frost | 00:09 |
Re: Bitmap scan is undercosted? | Vitaliy Garnashevich | 08:45 |
RE: Updating large tables without dead tuples | ldh@laurent-hasson.com | 17:19 |
Re: Updating large tables without dead tuples | Stephen Frost | 20:56 |
Re: Please help | PropAAS DBA | 20:58 |
Thread | Author | Time |
---|---|---|
Re: Performance | phb07 | 08:08 |
Thread | Author | Time |
---|---|---|
check_postgres via Nagios | daulat sagar | 05:27 |
Thread | Author | Time |
---|---|---|
Performance degrade in Planning Time to find appropriate Partial Index | Meenatchi Sandanam | 11:09 |
Re: Performance degrade in Planning Time to find appropriate Partial Index | Laurenz Albe | 13:03 |
Re: Performance degrade in Planning Time to find appropriate Partial Index | Michael Loftis | 14:16 |
Re: Performance degrade in Planning Time to find appropriate Partial Index 📎 | Moreno Andreo | 14:39 |
Thread | Author | Time |
---|---|---|
Re: Performance degrade in Planning Time to find appropriate Partial Index | Nandakumar M | 13:49 |
Re: Performance degrade in Planning Time to find appropriate Partial Index | Pavel Stehule | 14:29 |
Re: Performance degrade in Planning Time to find appropriate Partial Index | Pavel Stehule | 14:32 |
why does this query not use a parallel query | Dave Cramer | 16:29 |
Re: why does this query not use a parallel query | Tom Lane | 16:44 |
Thread | Author | Time |
---|---|---|
Re: Updating large tables without dead tuples | Vik Fearing | 01:55 |
Thread | Author | Time |
---|---|---|
Slow index scan backward. | John van Breda | 15:45 |
GIST index (polygon, point) | ghiureai | 16:18 |
Thread | Author | Time |
---|---|---|
Please help | Daulat Ram | 08:01 |
Re: GIST index (polygon, point) | Laurenz Albe | 09:59 |
by mistake dropped physical file dropped for one table. | Rambabu V | 11:35 |
need meta data table/command to find query log | Rambabu V | 11:38 |
Re: Please help | Tomas Vondra | 11:46 |
Re: by mistake dropped physical file dropped for one table. | Stephen Frost | 13:21 |
Re: need meta data table/command to find query log | Stephen Frost | 13:24 |
Re: by mistake dropped physical file dropped for one table. | Rambabu V | 13:27 |
Thread | Author | Time |
---|---|---|
Re: [HACKERS] proposal: schema variables 📎 | Pavel Stehule | 18:00 |
Thread | Author | Time |
---|---|---|
RE: Updating large tables without dead tuples | ldh@laurent-hasson.com | 23:42 |
Thread | Author | Time |
---|---|---|
Memory size | dangal | 12:48 |
Sv: Memory size | Andreas Joseph Krogh | 13:49 |
Re: Sv: Memory size | dangal | 13:57 |
Re: Memory size | Jeff Janes | 16:59 |
Re: Memory size | dangal | 17:33 |
Re: Memory size | Tomas Vondra | 18:12 |
Re: Memory size | dangal | 19:11 |
Sv: Re: Sv: Memory size | Andreas Joseph Krogh | 21:45 |
Re: Memory size | Jeff Janes | 23:16 |
Thread | Author | Time |
---|---|---|
Re: Memory size | dangal | 01:43 |
Re: [HACKERS] proposal: schema variables | Pavel Luzanov | 06:49 |
Re: [HACKERS] proposal: schema variables | Pavel Stehule | 06:54 |
Re: Memory size | dangal | 15:08 |
Re: [HACKERS] proposal: schema variables | Pavel Luzanov | 15:38 |
Re: [HACKERS] proposal: schema variables | Pavel Stehule | 16:13 |
Thread | Author | Time |
---|---|---|
Re: proposal: schema variables | Pavel Luzanov | 09:54 |
Re: proposal: schema variables | Pavel Stehule | 18:44 |
Thread | Author | Time |
---|---|---|
Too many .history file in pg_xlog takes lots of space | 彭昱傑 | 02:31 |
Re: Too many .history file in pg_xlog takes lots of space | Laurenz Albe | 05:56 |
Re: Too many .history file in pg_xlog takes lots of space | 彭昱傑 | 06:12 |
Re: Too many .history file in pg_xlog takes lots of space | Michael Paquier | 07:04 |
Re: Too many .history file in pg_xlog takes lots of space | Alvaro Herrera | 13:49 |
Re: Too many .history file in pg_xlog takes lots of space | Tom Lane | 15:29 |
Thread | Author | Time |
---|---|---|
Re: Too many .history file in pg_xlog takes lots of space | 彭昱傑 | 10:22 |
RE: PG 9.6 Slow inserts with long-lasting LWLocks 📎 | Pavel Suderevsky | 10:29 |
Thread | Author | Time |
---|---|---|
Re: PG 9.6 Slow inserts with long-lasting LWLocks | MichaelDBA | 13:42 |
Irrelevant columns cause massive performance change | Craig James | 20:37 |
Re: Irrelevant columns cause massive performance change | Andres Freund | 20:50 |
Re: Irrelevant columns cause massive performance change | Craig James | 21:06 |
Thread | Author | Time |
---|---|---|
Slow performance after restoring a dump | David Osborne | 15:13 |
Re: Slow performance after restoring a dump | Tom Lane | 15:35 |
Re: Slow performance after restoring a dump | David Osborne | 15:43 |
Re: Slow performance after restoring a dump | Tom Lane | 16:22 |
Re: Slow performance after restoring a dump | David Osborne | 16:33 |
RE: PG 9.6 Slow inserts with long-lasting LWLocks | Pavel Suderevsky | 17:26 |
Thread | Author | Time |
---|---|---|
Re: [HACKERS] proposal: schema variables 📎 | Pavel Stehule | 17:38 |
Thread | Author | Time |
---|---|---|
Re: [HACKERS] proposal: schema variables 📎 | Pavel Stehule | 05:24 |
badly scaling performance with appending to bytea | Gary Cowell | 12:03 |
Re: badly scaling performance with appending to bytea | Rick Otten | 12:12 |
Re: badly scaling performance with appending to bytea | Pavel Stehule | 12:56 |
Re: badly scaling performance with appending to bytea | Pavel Stehule | 12:59 |
Re: badly scaling performance with appending to bytea | Gary Cowell | 13:04 |
Re: badly scaling performance with appending to bytea | Pavel Stehule | 13:09 |
Thread | Author | Time |
---|---|---|
Re: [HACKERS] proposal: schema variables | Pavel Stehule | 05:37 |
DB corruption | Akshay Ballarpure | 07:59 |
Re: DB corruption | Michael Paquier | 08:04 |
Should from_collapse be switched off? (queries 10 times faster) | Peter | 10:03 |
Re: Should from_collapse be switched off? (queries 10 times faster) | Thomas Kellerer | 11:39 |
Re: Should from_collapse be switched off? (queries 10 times faster) | Laurenz Albe | 11:41 |
Re: Should from_collapse be switched off? (queries 10 times faster) | Tom Lane | 14:14 |
Re: Should from_collapse be switched off? (queries 10 times faster) | Peter | 14:30 |
Re: Should from_collapse be switched off? (queries 10 times faster) | Peter | 14:30 |
Re: DB corruption | Tom Lane | 15:08 |
Re: Should from_collapse be switched off? (queries 10 times faster) | Peter | 17:36 |
Slow planning time for custom function | bk | 20:28 |
Thread | Author | Time |
---|---|---|
functions: VOLATILE performs better than STABLE | Peter | 01:27 |
Re: Slow planning time for custom function | Andres Freund | 01:35 |
Re: Slow planning time for custom function | David Rowley | 01:52 |
Thread | Author | Time |
---|---|---|
Re: functions: VOLATILE performs better than STABLE | Laurenz Albe | 05:00 |
Re: Should from_collapse be switched off? (queries 10 times faster) | Laurenz Albe | 05:12 |
Re: functions: VOLATILE performs better than STABLE | David Rowley | 12:24 |
Re: Slow planning time for custom function | bk | 18:18 |