Mailing lists [pgsql-performance]

4 November 2019

• 06:04   Slow planning, fast execution for particular 3-table query David Wheeler
• 07:37   Re: Slow planning, fast execution for particular 3-table query Laurenz Albe
• 07:42   Re: Slow planning, fast execution for particular 3-table query David Wheeler
• 07:46   Re: Slow planning, fast execution for particular 3-table query Laurenz Albe
• 08:00   Re: Slow planning, fast execution for particular 3-table query Tom Lane
• 08:17   Re: Slow planning, fast execution for particular 3-table query David Wheeler
• 08:53   Re: Slow planning, fast execution for particular 3-table query Pavel Stehule
• 22:38   Huge shared hit for small table Scott Rankin
• 22:46   Re: Huge shared hit for small table Andres Freund
• 22:56   Re: Huge shared hit for small table Justin Pryzby
• 22:56   Re: Huge shared hit for small table Scott Rankin
• 23:07   Re: Huge shared hit for small table Peter Geoghegan
• 23:17   Re: Huge shared hit for small table Andres Freund
• 23:18   Re: Huge shared hit for small table Scott Rankin
• 23:31   Re: Huge shared hit for small table Jeff Janes
• 23:34   Re: Huge shared hit for small table Peter Geoghegan
• 23:38   Re: Huge shared hit for small table Scott Rankin
• 23:40   Re: Huge shared hit for small table Peter Geoghegan

5 November 2019

• 00:00   Re: Huge shared hit for small table Scott Rankin
• 00:05   Re: Huge shared hit for small table Jeff Janes
• 02:33   FPGA optimization ... Gunther
• 03:19   Re: FPGA optimization ... Tomas Vondra
• 07:52   Re: FPGA optimization ... Gunther

6 November 2019

• 21:01   Re: FPGA optimization ... AJG

7 November 2019

• 00:54   Re: FPGA optimization ... Tomas Vondra
• 01:46   Re: Slow planning, fast execution for particular 3-table query David Wheeler
• 01:56   Re: Slow planning, fast execution for particular 3-table query Michael Lewis
• 01:59   Re: Slow planning, fast execution for particular 3-table query Justin Pryzby
• 02:15   Re: FPGA optimization ... Andres Freund
• 02:41   Re: Slow planning, fast execution for particular 3-table query David Wheeler
• 03:15   Re: Slow planning, fast execution for particular 3-table query David Rowley
• 03:18   Re: Slow planning, fast execution for particular 3-table query Justin Pryzby
• 03:45   Re: FPGA optimization ... Tomas Vondra

12 November 2019

• 20:29   Slow "not in array" operation Marco Colli
• 21:39   Re: Slow "not in array" operation Michael Lewis
• 22:04   Re: Slow "not in array" operation Marco Colli
• 22:20   Re: Slow "not in array" operation Michael Lewis
• 22:53   Re: Slow "not in array" operation Justin Pryzby
• 23:06   Re: Slow "not in array" operation Marco Colli
• 23:31   Re: Slow "not in array" operation Michael Lewis
• 23:50   Re: Slow "not in array" operation Tom Lane

13 November 2019

• 00:40   Re: Slow "not in array" operation Marco Colli
• 02:33   Re: Slow "not in array" operation Jeff Janes
• 12:20   Re: Slow "not in array" operation Marco Colli
• 13:46   Re: Slow "not in array" operation Morris de Oryx
• 14:18   Re: Slow "not in array" operation Rick Otten
• 14:30   Re: Slow "not in array" operation Jeff Janes
• 14:56   Re: Slow "not in array" operation Marco Colli
• 15:18   Re: Slow "not in array" operation Jeff Janes
• 19:15   Re: Slow "not in array" operation Marco Colli
• 23:16   Parallel Query Luís Roberto Weck
• 23:40   Re: Parallel Query Jeff Janes
• 23:47   Re: Parallel Query Tomas Vondra

14 November 2019

• 00:04   Re: Parallel Query Luís Roberto Weck
• 00:07   Re: Parallel Query Luís Roberto Weck
• 01:08   Re: Parallel Query Jeff Janes
• 01:21   Re: Parallel Query Jeff Janes
• 14:14   Re: Parallel Query Luís Roberto Weck
• 16:55   JSON path Jesper Pedersen
• 21:04   Re: JSON path Tom Lane
• 23:46   Re: JSON path Jesper Pedersen

15 November 2019

• 01:19   Simple DELETE on modest-size table runs 100% CPU forever Craig James
• 01:22   Re: Simple DELETE on modest-size table runs 100% CPU forever Alvaro Herrera
• 01:24   Re: Simple DELETE on modest-size table runs 100% CPU forever Michael Lewis
• 01:28   Re: Simple DELETE on modest-size table runs 100% CPU forever Justin Pryzby
• 01:29   Re: Simple DELETE on modest-size table runs 100% CPU forever Andres Freund

16 November 2019

• 00:06   Re: Simple DELETE on modest-size table runs 100% CPU forever Craig James
• 00:11   RE: Simple DELETE on modest-size table runs 100% CPU forever Ravi Rai
• 01:44   Re: Simple DELETE on modest-size table runs 100% CPU forever Jeff Janes
• 03:26   Re: Simple DELETE on modest-size table runs 100% CPU forever Craig James
• 18:16   Re: Simple DELETE on modest-size table runs 100% CPU forever Jeff Janes
• 20:17   Re: Simple DELETE on modest-size table runs 100% CPU forever Craig James

18 November 2019

• 14:41   Out of memory error on automatic vacuum Ekaterina Amez
• 15:25   Re: Out of memory error on automatic vacuum Tomas Vondra
• 17:02   Re: Out of memory error on automatic vacuum Ekaterina Amez
• 17:16   Re: Out of memory error on automatic vacuum Tomas Vondra
• 17:46   Re: Out of memory error on automatic vacuum Ekaterina Amez
• 18:10   Re: Out of memory error on automatic vacuum Tomas Vondra
• 20:35   Wrong estimations and NL Anti join poor performance Andrew Zakharov

22 November 2019

• 14:21   Postgresql planning time too high Sterpu Victor
• 14:35   RE: Postgresql planning time too high Fırat Güleç
• 14:44   Re[2]: Postgresql planning time too high Sterpu Victor
• 14:46   Re[2]: Postgresql planning time too high Sterpu Victor
• 15:05   RE: Re[2]: Postgresql planning time too high Fırat Güleç
• 15:22   Re: Postgresql planning time too high Luís Roberto Weck
• 15:25   Re[4]: Postgresql planning time too high Sterpu Victor
• 15:44   Re[4]: Postgresql planning time too high Sterpu Victor
• 15:50   Re[3]: Postgresql planning time too high Sterpu Victor
• 15:59   Re: Re[2]: Postgresql planning time too high Pavel Stehule
• 16:45   Re[4]: Postgresql planning time too high Sterpu Victor
• 17:06   Re[4]: Postgresql planning time too high Sterpu Victor
• 17:29   Re: Re[4]: Postgresql planning time too high Pavel Stehule
• 20:33   Hash Join over Nested Loop Luís Roberto Weck
• 20:43   Re: Hash Join over Nested Loop Luís Roberto Weck
• 20:55   Re: Hash Join over Nested Loop Pavel Stehule
• 21:13   Re: Re[4]: Postgresql planning time too high Michael Lewis
• 21:48   Re: Hash Join over Nested Loop Luís Roberto Weck
• 21:54   Re: Hash Join over Nested Loop Pavel Stehule
• 22:36   Re: Postgresql planning time too high Tomas Vondra

24 November 2019

• 16:19   Re: performance degredation after upgrade from 9.6 to 12 Andrew Zakharov
• 16:51   Re: performance degredation after upgrade from 9.6 to 12 Mariel Cherkassky
• 18:30   Re: performance degredation after upgrade from 9.6 to 12 Jeff Janes
• 21:05   Re: performance degredation after upgrade from 9.6 to 12 Mariel Cherkassky
• 23:00   Re: performance degredation after upgrade from 9.6 to 12 John Felix
• 23:50   Re: performance degredation after upgrade from 9.6 to 12 Jeff Janes

25 November 2019

• 00:49   Re: performance degredation after upgrade from 9.6 to 12 Mariel Cherkassky

29 November 2019

• 13:04   Considerable performance downgrade of v11 and 12 on Windows Eugene Podshivalov
• 13:36   Re: Considerable performance downgrade of v11 and 12 on Windows Thomas Kellerer
• 13:47   Re: Considerable performance downgrade of v11 and 12 on Windows Eugene Podshivalov
• 15:04   Re: Considerable performance downgrade of v11 and 12 on Windows Laurenz Albe
• 15:22   Re: Considerable performance downgrade of v11 and 12 on Windows Eugene Podshivalov
• 19:06   Logical replication performance Florian Philippon
• 19:25   Re: Logical replication performance Flavio Henrique Araque Gurgel

30 November 2019

• 22:47   Re: Considerable performance downgrade of v11 and 12 on Windows Eugene Podshivalov