Mailing lists [pgsql-performance]

6 May 2019

• 17:43   PostgreSQL optimizer use seq scan instead of pkey index only scan (inqueries with postgres_fdw) Vitaly Baranovsky
• 18:32   Re: PostgreSQL optimizer use seq scan instead of pkey index only scan(in queries with postgres_fdw) Jeff Janes
• 18:38   Re: PostgreSQL optimizer use seq scan instead of pkey index only scan(in queries with postgres_fdw) Vitaly Baranovsky
• 18:53   Re: PostgreSQL optimizer use seq scan instead of pkey index only scan (in queries with postgres_fdw) Tom Lane
• 18:53   Re: PostgreSQL optimizer use seq scan instead of pkey index only scan(in queries with postgres_fdw) Jeff Janes
• 19:36   Re: PostgreSQL optimizer use seq scan instead of pkey index only scan(in queries with postgres_fdw) Vitaly Baranovsky
• 20:17   Re: PostgreSQL optimizer use seq scan instead of pkey index only scan(in queries with postgres_fdw) Jeff Janes

7 May 2019

• 19:14   GCC 8.3.0 vs. 9.0.1 Steven Winfield
• 20:05   Re: GCC 8.3.0 vs. 9.0.1 Tom Lane
• 20:28   Re: GCC 8.3.0 vs. 9.0.1 Peter Geoghegan
• 20:32   Re: GCC 8.3.0 vs. 9.0.1 Andres Freund
• 20:42   Re: GCC 8.3.0 vs. 9.0.1 Andres Freund
• 21:04   Re: GCC 8.3.0 vs. 9.0.1 Andres Freund

9 May 2019

• 07:14   Re: Re: Generic Plans for Prepared Statement are 158155 timesslower than Custom Plans Deepak Somaiya
• 17:04   RE: GCC 8.3.0 vs. 9.0.1 Steven Winfield

10 May 2019

• 17:10   Log size in bytes of query result Franklin Haut
• 19:09   Re: Log size in bytes of query result Laurenz Albe
• 19:42   Re: Log size in bytes of query result Sergei Kornilov

12 May 2019

• 17:08   Huge generated UNION ALL faster than JOIN? Ancoron Luciferis
• 21:08   Re: Huge generated UNION ALL faster than JOIN? Tom Lane

13 May 2019

• 01:23   Re: Huge generated UNION ALL faster than JOIN? Ancoron Luciferis

14 May 2019

• 19:08   The wrong (?) query plan for queries with remote (postgres_fdw) tables Vitaly Baranovsky

16 May 2019

• 23:03   Analyze results in more expensive query plan Jeremy Altavilla

17 May 2019

• 09:42   RE: Re: Re: Generic Plans for Prepared Statement are 158155 times slowerthan Custom Plans Naik, Sameer
• 12:15   using sequential scan instead of index for join with a union Kent Tong
• 12:23   Re: using sequential scan instead of index for join with a union Sergei Kornilov
• 12:36   Re: using sequential scan instead of index for join with a union Kent Tong
• 16:35   Re: Analyze results in more expensive query plan Tom Lane

20 May 2019

• 17:39   Trying to handle db corruption 9.6 Mariel Cherkassky
• 17:39   Trying to handle db corruption 9.6 Mariel Cherkassky
• 17:49   Re: Trying to handle db corruption 9.6 Flo Rance
• 17:49   Re: Trying to handle db corruption 9.6 Flo Rance
• 18:00   Re: Trying to handle db corruption 9.6 Mariel Cherkassky
• 18:00   Re: Trying to handle db corruption 9.6 Mariel Cherkassky
• 19:07   Re: Trying to handle db corruption 9.6 Mariel Cherkassky
• 19:20   Re: Trying to handle db corruption 9.6 Bimal
• 20:20   Re: Trying to handle db corruption 9.6 Mariel Cherkassky
• 23:19   Re: Analyze results in more expensive query plan Jeremy Altavilla
• 23:55   Re: Trying to handle db corruption 9.6 Tomas Vondra

21 May 2019

• 00:04   Re: Trying to handle db corruption 9.6 Tomas Vondra
• 00:37   Re: Re: Re: Generic Plans for Prepared Statement are 158155 timesslower than Custom Plans Deepak Somaiya
• 01:16   Re: Generic Plans for Prepared Statement are 158155 times slowerthan Custom Plans Tomas Vondra
• 03:43   Temporarily very slow planning time after a big delete Walter Smith
• 04:00   Re: Temporarily very slow planning time after a big delete David Rowley
• 04:04   Re: Temporarily very slow planning time after a big delete Tom Lane
• 05:04   Re: Analyze results in more expensive query plan David Rowley
• 05:04   Re: Temporarily very slow planning time after a big delete Walter Smith
• 05:12   Re: Temporarily very slow planning time after a big delete Walter Smith
• 05:15   Re: Temporarily very slow planning time after a big delete David Rowley
• 12:01   Re: Trying to handle db corruption 9.6 Mariel Cherkassky
• 16:07   Re: Trying to handle db corruption 9.6 Tomas Vondra
• 16:12   Re: Trying to handle db corruption 9.6 Mariel Cherkassky
• 19:37   Re: Trying to handle db corruption 9.6 Tomas Vondra
• 21:12   Re: Temporarily very slow planning time after a big delete Walter Smith
• 21:15   Re: Temporarily very slow planning time after a big delete Peter Geoghegan
• 21:16   Re: Temporarily very slow planning time after a big delete Walter Smith
• 21:17   Re: Temporarily very slow planning time after a big delete Peter Geoghegan
• 21:26   Re: Temporarily very slow planning time after a big delete Walter Smith
• 21:32   Re: Temporarily very slow planning time after a big delete didier
• 21:36   Re: Temporarily very slow planning time after a big delete Peter Geoghegan

22 May 2019

• 07:28   Use Postgres as a column store by creating one table per column Lev Kokotov
• 07:43   Re: Use Postgres as a column store by creating one table per column Justin Pryzby
• 15:50   Re: Log size in bytes of query result Franklin Haut
• 16:15   Re: Log size in bytes of query result Dmitry Dolgov
• 18:26   pg_restore takes more time on creation of rules Mariel Cherkassky
• 18:26   pg_restore takes more time on creation of rules Mariel Cherkassky
• 18:41   Re: pg_restore takes more time on creation of rules Tomas Vondra
• 18:41   Re: pg_restore takes more time on creation of rules Tomas Vondra
• 18:44   Re: pg_restore takes more time on creation of rules Mariel Cherkassky
• 18:44   Re: pg_restore takes more time on creation of rules Mariel Cherkassky
• 20:00   Re: pg_restore takes more time on creation of rules Tomas Vondra
• 20:00   Re: pg_restore takes more time on creation of rules Tomas Vondra

23 May 2019

• 01:21   Re: Analyze results in more expensive query plan Jeremy Altavilla
• 08:08   Re: Use Postgres as a column store by creating one table per column George Neuner
• 09:37   RE: Re: Generic Plans for Prepared Statement are 158155 times slower thanCustom Plans Naik, Sameer
• 14:07   Fwd: upgrade to PG11 on secondary fails (no initdb was launched) Mariel Cherkassky
• 14:23   RE: upgrade to PG11 on secondary fails (no initdb was launched) Greg Clough
• 14:31   Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched) Fabio Pardi
• 18:06   Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched) Stephen Frost
• 20:17   Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans Tom Lane

24 May 2019

• 21:06   Re: Use Postgres as a column store by creating one table per column Tomas Vondra
• 22:38   Re: Use Postgres as a column store by creating one table per column Stephen Frost

25 May 2019

• 06:55   Re: Use Postgres as a column store by creating one table per column Mark Kirkwood
• 16:45   UUID v1 optimizations... Ancoron Luciferis
• 17:19   Re: UUID v1 optimizations... Peter Eisentraut
• 17:57   Re: UUID v1 optimizations... Tom Lane
• 20:27   Re: UUID v1 optimizations... Ancoron Luciferis
• 21:20   Re: UUID v1 optimizations... Ancoron Luciferis
• 22:00   Re: UUID v1 optimizations... Vitalii Tymchyshyn

26 May 2019

• 00:02   Re: UUID v1 optimizations... Ancoron Luciferis
• 00:02   Re: UUID v1 optimizations... Ancoron Luciferis
• 00:54   Re: UUID v1 optimizations... Tom Lane
• 01:14   Re: UUID v1 optimizations... Tomas Vondra
• 01:38   Re: UUID v1 optimizations... Tom Lane
• 02:00   Re: UUID v1 optimizations... Ancoron Luciferis
• 02:44   Re: UUID v1 optimizations... Tomas Vondra
• 02:49   Re: UUID v1 optimizations... Ancoron Luciferis
• 04:09   Re: UUID v1 optimizations... Tomas Vondra
• 07:27   Re: UUID v1 optimizations... Morris de Oryx
• 12:01   Re: UUID v1 optimizations... Ancoron Luciferis
• 12:38   Re: UUID v1 optimizations... Ancoron Luciferis
• 13:24   Re: UUID v1 optimizations... Morris de Oryx
• 13:37   Re: UUID v1 optimizations... Tomas Vondra
• 13:38   Re: UUID v1 optimizations... Morris de Oryx
• 13:46   Re: UUID v1 optimizations... Morris de Oryx

27 May 2019

• 11:49   improve wals replay on secondary Mariel Cherkassky
• 12:12   Re: improve wals replay on secondary Fabio Pardi
• 12:29   Re: improve wals replay on secondary Fabio Pardi
• 13:17   Re: improve wals replay on secondary Mariel Cherkassky
• 14:04   Re: improve wals replay on secondary Fabio Pardi

28 May 2019

• 13:54   Re: improve wals replay on secondary Fabio Pardi

29 May 2019

• 10:20   Re: improve wals replay on secondary Mariel Cherkassky
• 11:02   JIT in PostgreSQL 12 ? Tobias Gierke
• 11:20   Re: improve wals replay on secondary Fabio Pardi
• 11:39   Re: improve wals replay on secondary Mariel Cherkassky
• 11:48   Sv: JIT in PostgreSQL 12 ? Andreas Joseph Krogh
• 12:13   Re: Sv: JIT in PostgreSQL 12 ? Tobias Gierke
• 12:16   Re: Sv: JIT in PostgreSQL 12 ? Andreas Joseph Krogh
• 12:37   Re: JIT in PostgreSQL 12 ? Andreas Karlsson
• 13:54   Re: improve wals replay on secondary Nikolay Samokhvalov
• 14:10   Re: improve wals replay on secondary Mariel Cherkassky

30 May 2019

• 18:08   Shortest offline window on database migration Haroldo Kerry
• 18:31   Re: Shortest offline window on database migration Tomas Vondra
• 18:54   RE: Shortest offline window on database migration Steven Winfield
• 19:23   Re: Shortest offline window on database migration Haroldo Kerry

31 May 2019

• 00:52   Re: Shortest offline window on database migration Haroldo Kerry
• 04:41   Re: Shortest offline window on database migration Jeff Janes
• 05:49   Re: Shortest offline window on database migration Ian Lawrence Barwick
• 12:40   Re: Shortest offline window on database migration Fabio Pardi
• 14:54   Re: improve wals replay on secondary Fabio Pardi