Mailing lists [pgsql-performance]

1 November 2017

• 01:25   Re: [PERFORM] Index-Advisor Tools Alexandre de Arruda Paes
• 02:04   Re: [PERFORM] Index-Advisor Tools Yves Dorfsman
• 02:04   Re: [PERFORM] Index-Advisor Tools Julien Rouhaud
• 22:28   Re: [PERFORM] Cursor vs Set Operation Merlin Moncure

2 November 2017

• 06:28   [PERFORM] OLAP/reporting queries fall into nested loops over seq scans or otherhorrible planner choices Gunther
• 08:44   Re: [PERFORM] OLAP/reporting queries fall into nested loops over seqscans or other horrible planner choices ldh@laurent-hasson.com
• 14:30   Re: [PERFORM] OLAP/reporting queries fall into nested loops overseq scans or other horrible planner choices Laurenz Albe
• 22:36   Re: [PERFORM] OLAP/reporting queries fall into nested loops over seqscans or other horrible planner choices Gunther
• 23:14   Re: [PERFORM] OLAP/reporting queries fall into nested loops over seqscans or other horrible planner choices Gunther

3 November 2017

• 00:03   [PERFORM] Re: OLAP/reporting queries fall into nested loops over seq scans orother horrible planner choices legrand legrand
• 14:01   Re: [PERFORM] OLAP/reporting queries fall into nested loops overseq scans or other horrible planner choices Laurenz Albe
• 15:28   [PERFORM] Re: OLAP/reporting queries fall into nested loops over seq scans orother horrible planner choices Thomas Kellerer
• 18:07   Re: [PERFORM] Re: OLAP/reporting queries fall into nested loops overseq scans or other horrible planner choices Adam Brusselback
• 20:36   Re: [PERFORM] Re: OLAP/reporting queries fall into nested loops overseq scans or other horrible planner choices Gunther
• 20:51   Re: [PERFORM] Re: OLAP/reporting queries fall into nested loops overseq scans or other horrible planner choices Gunther
• 20:55   [PERFORM] Re: OLAP/reporting queries fall into nested loops over seq scans orother horrible planner choices legrand legrand
• 21:13   Re: [PERFORM] Re: OLAP/reporting queries fall into nested loops overseq scans or other horrible planner choices Gunther
• 21:56   Re: [PERFORM] Re: OLAP/reporting queries fall into nested loops overseq scans or other horrible planner choices Dave Nicponski

4 November 2017

• 21:20   [PERFORM] Unnecessary DISTINCT while primary key in SQL 刘瑞

6 November 2017

• 06:34   Re: [PERFORM] Unnecessary DISTINCT while primary key in SQL David Rowley
• 19:18   [PERFORM] Performance loss upgrading from 9.3 to 9.6 Adam Torres
• 20:21   Re: [PERFORM] Performance loss upgrading from 9.3 to 9.6 Justin Pryzby

7 November 2017

• 00:52   Re: [PERFORM] Index-Advisor Tools Baron Schwartz
• 02:05   [PERFORM] Dynamic performance issues Arne Roland
• 03:12   Re: [PERFORM] Performance loss upgrading from 9.3 to 9.6 Adam Torres
• 08:59   Re: [PERFORM] Performance loss upgrading from 9.3 to 9.6 Adam Brusselback
• 11:11   Re: [PERFORM] Performance loss upgrading from 9.3 to 9.6 Justin Pryzby
• 16:11   [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Ulf Lohbrügge
• 21:11   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESETROLE Andres Freund
• 23:48   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Ulf Lohbrügge

8 November 2017

• 01:45   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESETROLE Andres Freund
• 03:25   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Ulf Lohbrügge
• 03:39   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Scott Marlowe
• 05:04   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Ulf Lohbrügge
• 05:45   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Tom Lane
• 15:31   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Ulf Lohbrügge

10 November 2017

• 16:58   [PERFORM] DB slowness after upgrade from Postgres 9.1 to 9.4 p kirti

11 November 2017

• 02:40   [PERFORM] overestimate on empty table Justin Pryzby
• 03:19   Re: [PERFORM] overestimate on empty table Tom Lane
• 23:19   Re: [PERFORM] overestimate on empty table Justin Pryzby
• 23:43   Re: [PERFORM] overestimate on empty table Tom Lane

13 November 2017

• 01:37   Re: [PERFORM] DB slowness after upgrade from Postgres 9.1 to 9.4 Tom Lane
• 22:44   [PERFORM] Query planner gaining the ability to replanning after start of query execution. Oliver Mattos

14 November 2017

• 02:06   Re: [PERFORM] Query planner gaining the ability to replanning afterstart of query execution. Arne Roland
• 03:51   Re: [PERFORM] Query planner gaining the ability to replanning afterstart of query execution. Oliver Mattos
• 04:48   Re: [PERFORM] Query planner gaining the ability to replanning afterstart of query execution. Arne Roland
• 04:49   Re: [PERFORM] Query planner gaining the ability to replanning after start of query execution. Tom Lane
• 05:20   Re: [PERFORM] Query planner gaining the ability to replanning afterstart of query execution. Oliver Mattos

15 November 2017

• 03:26   [PERFORM] Re: Query planner gaining the ability to replanning after start ofquery execution. legrand legrand
• 15:33   [PERFORM] query performance issue Samir Magar
• 15:43   Re: [PERFORM] query performance issue Pavel Stehule
• 18:54   Re: [PERFORM] query performance issue Samir Magar
• 19:12   Re: [PERFORM] query performance issue Pavel Stehule
• 20:16   Re: [PERFORM] query performance issue Justin Pryzby

16 November 2017

• 01:57   [PERFORM] Re: Query planner gaining the ability to replanning after start ofquery execution. Gunter
• 01:58   Re: [PERFORM] query performance issue Gunther
• 02:07   Re: [PERFORM] query performance issue Pavel Stehule
• 02:19   [PERFORM] CREATE STATISTICS and join selectivity Justin Pryzby
• 05:47   Re: [PERFORM] CREATE STATISTICS and join selectivity David Rowley

18 November 2017

• 07:52   [PERFORM] POWA doesn't show queries executed Neto pr

20 November 2017

• 15:02   [PERFORM] PostgreSQL 9.6 wals management Mariel Cherkassky
• 18:28   Re: [PERFORM] PostgreSQL 9.6 wals management Michael Paquier
• 18:56   Re: [PERFORM] PostgreSQL 9.6 wals management Mariel Cherkassky
• 20:33   [PERFORM] Migration to pglister - Before Stephen Frost
• 21:03   Migration to PGLister - After Stephen Frost

21 November 2017

• 04:54   insert and query performance on big string table with pg_trgm Matthew Hall
• 07:42   Re: insert and query performance on big string table with pg_trgm Jeff Janes
• 14:00   Re: [PERFORM] POWA doesn't show queries executed phb07
• 14:05   Re: insert and query performance on big string table with pg_trgm Matthew Hall
• 17:04   Using GROUPING SETS with more than one set disables predicate pushdown? Zakhar Shapurau
• 20:28   pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 20:49   Re: Using GROUPING SETS with more than one set disables predicate pushdown? Tom Lane
• 21:29   Re: [PERFORM] POWA doesn't show queries executed Marco Nietz
• 22:25   RE: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Igor Neyman
• 22:27   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 22:34   RE: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Igor Neyman
• 22:37   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 22:44   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Shaul Dar
• 22:44   RE: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Igor Neyman
• 22:48   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 22:57   RE: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Igor Neyman
• 23:01   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Tom Lane

22 November 2017

• 00:16   Re: Using GROUPING SETS with more than one set disables predicate pushdown? Andres Freund
• 00:16   Re: Using GROUPING SETS with more than one set disables predicate pushdown? Andres Freund
• 00:39   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Robert Haas
• 00:46   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Tom Lane
• 00:53   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 00:59   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 03:01   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Tom Lane
• 09:48   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 12:18   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 16:32   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Matthew Hall
• 18:17   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 19:06   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 20:13   Query became very slow after 9.6 -> 10 upgrade Dmitry Shalashov
• 20:24   RE: Query became very slow after 9.6 -> 10 upgrade Alex Ignatov
• 20:29   Re: Query became very slow after 9.6 -> 10 upgrade Dmitry Shalashov
• 20:29   Bad estimates Artur Zając
• 20:44   RE: Query became very slow after 9.6 -> 10 upgrade Alex Ignatov
• 20:49   Re: Bad estimates Don Seiler
• 20:51   Re: Query became very slow after 9.6 -> 10 upgrade Dmitry Shalashov
• 20:57   Re: Bad estimates (DEFAULT_UNK_SEL) Justin Pryzby
• 21:01   Re: Bad estimates Tom Lane
• 21:05   RE: Bad estimates Alex Ignatov
• 21:07   Re: Query became very slow after 9.6 -> 10 upgrade Tomas Vondra
• 21:09   Re: Bad estimates Laurenz Albe
• 21:19   Re: Query became very slow after 9.6 -> 10 upgrade Tom Lane
• 22:52   RE: Bad estimates Artur Zając
• 22:56   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Andres Freund

23 November 2017

• 01:52   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Matthew Hall
• 02:06   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 03:07   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Patrick KUI-LI
• 03:34   Re: Query became very slow after 9.6 -> 10 upgrade Dmitry Shalashov
• 05:07   Re: Query became very slow after 9.6 -> 10 upgrade Tom Lane
• 05:07   Re: Query became very slow after 9.6 -> 10 upgrade Tom Lane
• 15:26   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Henrik Cednert (Filmlance)
• 20:58   Re: Query became very slow after 9.6 -> 10 upgrade Dmitry Shalashov
• 20:58   Re: Query became very slow after 9.6 -> 10 upgrade Dmitry Shalashov
• 23:00   Re: Query became very slow after 9.6 -> 10 upgrade Tom Lane

24 November 2017

• 00:14   pgpool + repmgr - who should be responsible for failover Mariel Cherkassky
• 09:27   Issue with postgres login Daulat Ram
• 09:37   Re: Issue with postgres login Bob Strecansky
• 10:04   RE: Re: Issue with postgres login Daulat Ram
• 10:07   Re: Re: Issue with postgres login Bob Strecansky
• 10:23   RE: Re: Re: Issue with postgres login Daulat Ram
• 10:25   Re: Re: Re: Issue with postgres login Bob Strecansky
• 12:49   RE: Re: Re: Re: Issue with postgres login Daulat Ram
• 21:44   Re: Query became very slow after 9.6 -> 10 upgrade Dmitry Shalashov
• 22:39   Re: Query became very slow after 9.6 -> 10 upgrade Tom Lane

25 November 2017

• 12:35   Re: insert and query performance on big string table with pg_trgm Jeff Janes
• 15:19   Re: insert and query performance on big string table with pg_trgm Gábor SZŰCS
• 17:54   Re: Query became very slow after 9.6 -> 10 upgrade Dmitry Shalashov
• 18:13   Re: Query became very slow after 9.6 -> 10 upgrade Michael Paquier
• 21:39   Re: Query became very slow after 9.6 -> 10 upgrade Dmitry Shalashov
• 21:42   Re: Query became very slow after 9.6 -> 10 upgrade Tom Lane

26 November 2017

• 00:59   Re: Query became very slow after 9.6 -> 10 upgrade Dmitry Shalashov

27 November 2017

• 23:58   Half billion records in one table? RDS Jean Baro

28 November 2017

• 00:18   Re: Half billion records in one table? RDS Laurenz Albe
• 00:23   Setting effective_io_concurrency in VM? Don Seiler
• 00:40   Re: Setting effective_io_concurrency in VM? Scott Marlowe
• 03:06   Re: Setting effective_io_concurrency in VM? Fernando Hevia
• 03:44   Re: Setting effective_io_concurrency in VM? Andrew Kerber
• 04:03   Re: Setting effective_io_concurrency in VM? Don Seiler
• 05:18   Re: Setting effective_io_concurrency in VM? Jeff Janes
• 05:57   Re: Setting effective_io_concurrency in VM? Andres Freund
• 16:13   Bad plan chosen for union all Alex Reece

29 November 2017

• 00:56   Invalid mem alloc request on function bima p
• 09:39   Re: Bad plan chosen for union all Alex Reece
• 10:43   Re: Bad plan chosen for union all Tom Lane
• 11:31   Re: Bad plan chosen for union all Alex Reece
• 20:47   ODBC--call failed :: Bindings were not allocated properly Dinesh Chandra 12108

30 November 2017

• 18:07   CREATE TABLE vs CREATE MATERIALIZED VIEW Caio Guimarães Figueiredo