Mailing lists [pgsql-performance]

1 December 2017

• 19:03   Delete tables difference involves seq scan Danylo Hlynskyi
• 19:17   Re: Delete tables difference involves seq scan Danylo Hlynskyi
• 20:52   Re: Delete tables difference involves seq scan Danylo Hlynskyi
• 23:20   Bad plan for ltree predicate <@ Roman Konoval
• 23:40   Bitmap scan is undercosted? Vitaliy Garnashevich

2 December 2017

• 00:34   Re: Bitmap scan is undercosted? Justin Pryzby
• 03:33   Re: Bad plan for ltree predicate <@ Tom Lane
• 05:08   Re: Bitmap scan is undercosted? Vitaliy Garnashevich
• 05:11   Re: Bitmap scan is undercosted? Justin Pryzby
• 05:54   Re: Bitmap scan is undercosted? Vitaliy Garnashevich
• 08:06   Re: Bitmap scan is undercosted? pryzby@telsasoft.com (Justin Pryzby)
• 08:34   Re: Bad plan for ltree predicate <@ Roman Konoval
• 11:51   Re: Bitmap scan is undercosted? Jeff Janes
• 12:41   Re: Bitmap scan is undercosted? Justin Pryzby
• 13:08   Re: Bitmap scan is undercosted? Vitaliy Garnashevich

3 December 2017

• 03:17   Re: Bitmap scan is undercosted? Jeff Janes
• 05:44   Re: Bitmap scan is undercosted? Tom Lane
• 07:27   Re: Bitmap scan is undercosted? Jeff Janes
• 10:04   Re: Bitmap scan is undercosted? - boolean correlation Justin Pryzby

4 December 2017

• 03:15   Re: Bitmap scan is undercosted? Vitaliy Garnashevich
• 03:22   Re: Bitmap scan is undercosted? Vitaliy Garnashevich
• 04:11   Re: Bitmap scan is undercosted? Vitaliy Garnashevich
• 05:08   Re: Bitmap scan is undercosted? Tom Lane
• 05:08   Re: Bitmap scan is undercosted? Tom Lane
• 05:21   Re: Bitmap scan is undercosted? - boolean correlation Jeff Janes
• 05:31   Re: Bitmap scan is undercosted? - boolean correlation Tom Lane
• 06:27   Re: Bitmap scan is undercosted? - boolean correlation Jeff Janes

5 December 2017

• 20:03   vacuum after truncate Mariel Cherkassky
• 20:40   Re: vacuum after truncate Laurenz Albe
• 22:21   Extremely slow DELETE with cascade foreign keys Rodrigo Rosenfeld Rosas
• 22:27   Re: Extremely slow DELETE with cascade foreign keys Tom Lane
• 22:43   Re: Extremely slow DELETE with cascade foreign keys Alvaro Herrera
• 23:00   Re: Extremely slow DELETE with cascade foreign keys Rodrigo Rosenfeld Rosas
• 23:22   Re: Extremely slow DELETE with cascade foreign keys Rodrigo Rosenfeld Rosas
• 23:25   Re: Extremely slow DELETE with cascade foreign keys Tom Lane
• 23:27   Re: Extremely slow DELETE with cascade foreign keys Rodrigo Rosenfeld Rosas
• 23:49   Re: Extremely slow DELETE with cascade foreign keys Alvaro Herrera

6 December 2017

• 00:04   Different plan chosen when in lateral subquery Alex Reece
• 00:08   Re: Different plan chosen when in lateral subquery Alex Reece
• 00:15   Re: Extremely slow DELETE with cascade foreign keys Rodrigo Rosenfeld Rosas
• 00:16   Re: Different plan chosen when in lateral subquery Alex Reece
• 00:17   Re: Extremely slow DELETE with cascade foreign keys Rodrigo Rosenfeld Rosas
• 00:50   Re: Bitmap scan is undercosted? - boolean correlation Tom Lane
• 07:59   Re: Half billion records in one table? RDS Aaron Werman
• 12:15   Re: insert and query performance on big string table with pg_trgm Matthew Hall
• 13:06   Re: Bitmap scan is undercosted? Vitaliy Garnashevich
• 13:23   Re: insert and query performance on big string table with pg_trgm Sergei Kornilov
• 14:20   Re: Different plan chosen when in lateral subquery Laurenz Albe

7 December 2017

• 03:46   Re: Bitmap scan is undercosted? - overestimated correlation andcost_index Justin Pryzby
• 06:17   Re: Bitmap scan is undercosted? Vitaliy Garnashevich
• 08:04   Re: insert and query performance on big string table with pg_trgm Matthew Hall
• 09:48   Re: Bitmap scan is undercosted? Jeff Janes
• 10:51   Re: Bitmap scan is undercosted? - boolean correlation Jeff Janes
• 18:46   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Gunther
• 18:54   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Ulf Lohbrügge
• 22:01   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Tom Lane
• 22:15   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Ulf Lohbrügge
• 22:38   Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE Tom Lane
• 23:31   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Laurenz Albe
• 23:56   Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade Claudio Freire

8 December 2017

• 07:12   Learning EXPLAIN Flávio Henrique
• 10:21   Table with large number of int columns, very slow COPY FROM Alex Tokarev
• 10:51   Re: Setting effective_io_concurrency in VM? Mark Kirkwood
• 13:20   Re: Table with large number of int columns, very slow COPY FROM Andreas Kretschmer
• 19:20   Re: Learning EXPLAIN Guillaume Lelarge
• 19:32   Re: Learning EXPLAIN Flavio Henrique Araque Gurgel
• 22:44   Re: Learning EXPLAIN Gustavo Velasquez

9 December 2017

• 00:17   Re: Table with large number of int columns, very slow COPY FROM Andres Freund
• 10:47   Re: Learning EXPLAIN Sam Gendler
• 10:52   Re: Learning EXPLAIN Sam Gendler

11 December 2017

• 06:39   Prepared Transactions Riaan Stander
• 14:14   Re: Prepared Transactions Sergei Kornilov
• 18:13   Re: Prepared Transactions jwhiting@redhat.com

12 December 2017

• 13:29   Re: Bitmap scan is undercosted? Jeff Janes
• 15:29   Re: Bitmap scan is undercosted? - overestimated correlation and cost_index Jeff Janes
• 21:15   PostgreSQL database size is not reasonable Mariel Cherkassky
• 21:21   Re: PostgreSQL database size is not reasonable David G. Johnston
• 21:44   RE: PostgreSQL database size is not reasonable Craig McIlwee
• 21:49   Re: PostgreSQL database size is not reasonable Tom Lane
• 22:22   Re: PostgreSQL database size is not reasonable Mariel Cherkassky
• 23:59   Re: PostgreSQL database size is not reasonable Tom Lane

13 December 2017

• 16:12   CPU 100% usage caused by iso-8859-1 postgres process.. Dinesh Chandra 12108
• 16:36   Re: CPU 100% usage caused by iso-8859-1 postgres process.. Laurenz Albe
• 18:19   Re: CPU 100% usage caused by iso-8859-1 postgres process.. Justin Pryzby
• 21:22   Re: CPU 100% usage caused by iso-8859-1 postgres process.. Tomas Vondra

16 December 2017

• 02:54   Re: Bitmap scan is undercosted? - overestimated correlation andcost_index Justin Pryzby

17 December 2017

• 01:18   Re: Bitmap scan is undercosted? - overestimated correlation andcost_index Justin Pryzby
• 08:37   Re: Bitmap scan is undercosted? - overestimated correlation andcost_index Justin Pryzby

19 December 2017

• 06:00   WHERE IN for JOIN subquery? Dave Johansen
• 06:10   Re: WHERE IN for JOIN subquery? David G. Johnston
• 06:29   Re: WHERE IN for JOIN subquery? Dave Johansen
• 22:47   Autoanalyze CPU usage Habib Nahas
• 23:09   Re: Autoanalyze CPU usage Justin Pryzby

20 December 2017

• 04:03   Re: Autoanalyze CPU usage Tomas Vondra
• 04:53   Re: Autoanalyze CPU usage Habib Nahas
• 04:53   Re: Autoanalyze CPU usage Habib Nahas
• 04:55   Re: Autoanalyze CPU usage Justin Pryzby
• 07:10   Re: Autoanalyze CPU usage Michaeldba@sqlexec.com
• 13:15   Re: Autoanalyze CPU usage Laurenz Albe
• 14:24   Re: Autoanalyze CPU usage Nikolay Samokhvalov
• 20:38   Re: Autoanalyze CPU usage Habib Nahas

22 December 2017

• 22:46   Updating a large table Timokhin Maxim

23 December 2017

• 17:31   Re: Updating a large table salah jubeh

24 December 2017

• 02:58   Re: Updating a large table Tomas Vondra

25 December 2017

• 01:51   Batch insert heavily affecting query performance. Jean Baro
• 05:52   Re: Batch insert heavily affecting query performance. MichaelDBA@sqlexec.com
• 06:09   Re: Batch insert heavily affecting query performance. Jean Baro
• 07:30   Re: Batch insert heavily affecting query performance. MichaelDBA
• 08:59   Re: Batch insert heavily affecting query performance. Danylo Hlynskyi
• 09:10   Re: Batch insert heavily affecting query performance. Jean Baro

27 December 2017

• 21:58   RE: Batch insert heavily affecting query performance. Mike Sofen
• 22:02   Re: Batch insert heavily affecting query performance. Jeremy Finzel
• 22:23   Re: Batch insert heavily affecting query performance. Jeff Janes
• 22:23   Re: Batch insert heavily affecting query performance. Jean Baro
• 22:34   Re: Batch insert heavily affecting query performance. Jean Baro
• 22:36   RE: Batch insert heavily affecting query performance. Jean Baro
• 22:37   Re: Batch insert heavily affecting query performance. Jean Baro
• 23:02   Re: Batch insert heavily affecting query performance. Jean Baro
• 23:09   Re: Batch insert heavily affecting query performance. Alvaro Hernandez
• 23:10   RE: Batch insert heavily affecting query performance. Mike Sofen
• 23:15   Re: Batch insert heavily affecting query performance. David Miller

28 December 2017

• 06:54   Table performance with millions of rows Robert Blayzor
• 07:20   Re: Table performance with millions of rows (partitioning) Justin Pryzby
• 07:27   Re: Table performance with millions of rows (partitioning) Robert Blayzor
• 08:22   Re: Table performance with millions of rows (partitioning) pinker

30 December 2017

• 10:37   partitioning an existing table Robert Blayzor
• 11:38   Re: partitioning an existing table Justin Pryzby
• 11:56   analyze stats: child vs parent Justin Pryzby
• 20:19   Re: partitioning an existing table Robert Blayzor

31 December 2017

• 00:42   Re: partitioning an existing table - efficient pg_dump Justin Pryzby