Re: Very slow "bloat query"

PostgreSQL 9.6.21 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit pt., 14 maj 2021 o 15:45 Imre Samu napisał(a): > > Unfortunately it's still 9.6. > > And what is your "*version()*"? > > > for example: > postgres=# select version(); >

Re: Very slow "bloat query"

There is a long running analytics query (which is running usually for 30-40 hours). I agree that's not the best position to be in but right now can't do anything about it. pt., 14 maj 2021 o 15:04 Tom Lane napisał(a): > Marcin Gozdalik writes: > > I have traced the problem to the bloated `pg_cl

Re: Very slow "bloat query"

> Unfortunately it's still 9.6. And what is your "*version()*"? for example: postgres=# select version(); version

Re: BUG #16968: Planner does not recognize optimization

Thank you for detailed explanation. I glad to hear that I can use aliases and this will be recognized and optimization is applied. >We'd need some sort of ability to assign ressortgroupref to a particular column within awhole-row varCould it be possible to create hidden alias in same way as I did t

Re: Very slow "bloat query"

Unfortunately it's still 9.6. Upgrade to latest 13 is planned for this year. pt., 14 maj 2021 o 12:08 Imre Samu napisał(a): > > Apart from the above hack of filtering out live tuples to a separate > table is there anything I could do? > > This is the latest PG13.3 version? > > IMHO: If not, m

Re: Very slow "bloat query"

Marcin Gozdalik writes: > I have traced the problem to the bloated `pg_class` (the irony: `pgmetrics` > does not collect bloat on `pg_catalog`): > `vacuum (full, analyze, verbose) pg_class;` > ``` > INFO: vacuuming "pg_catalog.pg_class" > INFO: "pg_class": found 1 removable, 7430805 nonremovable

Re: Very slow "bloat query"

> Apart from the above hack of filtering out live tuples to a separate table is there anything I could do? This is the latest PG13.3 version? IMHO: If not, maybe worth updating to the latest patch release, as soon as possible https://www.postgresql.org/docs/release/13.3/ Release date: 2021-05

Re: Very slow "bloat query"

Le 14/05/2021 à 13:06, Marcin Gozdalik a écrit : Hi I am trying to use `pgmetrics` on a big (10TB+), busy (1GB/s RW) database. It takes around 5 minutes for pgmetrics to run. I traced the problem to the "bloat query" (version of https://wiki.postgresql.org/wiki/Show_database_bloat

Very slow "bloat query"

Hi I am trying to use `pgmetrics` on a big (10TB+), busy (1GB/s RW) database. It takes around 5 minutes for pgmetrics to run. I traced the problem to the "bloat query" (version of https://wiki.postgresql.org/wiki/Show_database_bloat) spinning in CPU, doing no I/O. I have traced the problem to the

RE: Re: PostgreSQL blocked locks query

Hi , Thank you for the reply. Is there a similar way to extract the same from a SQL command ? Thanks -Original Message- From: Justin Pryzby Sent: Thursday, May 13, 2021 10:09 PM To: Manoj Kumar Cc: pgsql-performa...@postgresql.org Subject: [EXT MSG] Re: PostgreSQL blocked locks query

Re: BUG #16968: Planner does not recognize optimization

On Fri, 14 May 2021 at 02:38, Eugen Konkov wrote: > Now I create minimal reproducible test case. > https://dbfiddle.uk/?rdbms=postgres_13&fiddle=761a00fb599789d3db31b120851d6341 > > Optimization is not applyed when I filter/partition by column using composite > type name. You probably already kn