Re: Query on pg_stat_activity table got stuck

2019-05-11 Thread Tom Lane
I wrote: > This patch is against HEAD --- I've not looked at how much adjustment > it'll need for the back branches, but I'm sure there's some. I've back-patched this now. If you want to test the patch, the v10-branch version is at

Re: Linked data from upgrade after VACUUM FULL not deleted.

2019-05-11 Thread Bruce Momjian
On Sat, May 11, 2019 at 07:04:32PM +0200, Josef Šimánek wrote: > Hello. > > Few months ago we did successful pg_upgrade --link from 9.6 to 10. I did a > VACUUM FULL of all database this weekend and data from 9.6 directory were not > released. > > I have tablespace with only one database. > >

Re: Hot Standby Conflict on pg_attribute

2019-05-11 Thread Erik Jones
Thanks for the ti On Sat, May 11, 2019 at 9:15 AM Jeremy Schneider wrote: > Just a quick footnote: If autovac truncations are frequently causing > replica lag, and if this is a problem for you, IIUC one way you can stop > autovac from doing the truncations even on older versions is setting >

Linked data from upgrade after VACUUM FULL not deleted.

2019-05-11 Thread Josef Šimánek
Hello. Few months ago we did successful pg_upgrade --link from 9.6 to 10. I did a VACUUM FULL of all database this weekend and data from 9.6 directory were not released. I have tablespace with only one database. PostgreSQL 10 folder has similar size to actual database size (by

Re: Optimizing Database High CPU

2019-05-11 Thread Scottix
Hey, So I finally found the culprit. Turns out to be the THP fighting with itself. After running on Ubuntu echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag It instantly went from a loadavg of 30 to 3 Also make sure you re-enable on

Re: Hot Standby Conflict on pg_attribute

2019-05-11 Thread Jeremy Schneider
Just a quick footnote: If autovac truncations are frequently causing replica lag, and if this is a problem for you, IIUC one way you can stop autovac from doing the truncations even on older versions is setting old_snapshot_threshold to any value at all besides zero. (On 12+ you can directly

Re: Question about Expected rows value in EXPLAIN output for Nested Loop node

2019-05-11 Thread Tom Lane
bb ddd writes: > Thanks, Adrian, but i was looking for something that goes into more depth. Use the source, Luke. git clone git://git.postgresql.org/git/postgresql.git Likely places to look for this purpose include src/backend/optimizer/README src/backend/optimizer/path/costsize.c

Re: perl path issue

2019-05-11 Thread Adrian Klaver
On 5/10/19 6:49 PM, Prakash Ramakrishnan wrote: Hi Adrian, If I am following the below correctly you have EDB Postgres and pgBackRest running together on the prod server, correct? If so what was done different/is different on the dev server? 1) How was the production Postgres 

Re: Question about Expected rows value in EXPLAIN output for Nested Loop node

2019-05-11 Thread Adrian Klaver
On 5/11/19 2:33 AM, bb ddd wrote: Thanks, Adrian, but i was looking for something that goes into more depth. For example there is one case described there where we have a Nested Loop with rows=33, and its 2 child nodes have each rows=10. But first of all this is a very exotic join condition

Re: Question about Expected rows value in EXPLAIN output for Nested Loop node

2019-05-11 Thread bb ddd
Thanks, Adrian, but i was looking for something that goes into more depth. For example there is one case described there where we have a Nested Loop with rows=33, and its 2 child nodes have each rows=10. But first of all this is a very exotic join condition (t1.hundred < t2.hundred) and second

Re: PG version recommendation

2019-05-11 Thread Peter J. Holzer
On 2019-05-08 13:41:08 +0900, Ian Barwick wrote: > On Wed, 8 May 2019 at 07:19, Tim Cross wrote: > > I would find out if the IT team who will maintain the system are running > a specific Linux distribution, such as RHEL and just go with the PG > version that is on that distribution.