On Thu, Aug 12, 2021 at 06:20:23PM +0200, Magnus Hagander wrote:
> On Thu, Aug 12, 2021 at 4:38 PM hubert depesz lubaczewski
> wrote:
> >
> > On Thu, Aug 12, 2021 at 11:32:15AM +0200, Magnus Hagander wrote:
> > > Which database are you connected to? If you just want to look at the
> > > global sta
On Thu, Aug 12, 2021 at 4:38 PM hubert depesz lubaczewski
wrote:
>
> On Thu, Aug 12, 2021 at 11:32:15AM +0200, Magnus Hagander wrote:
> > Which database are you connected to? If you just want to look at the
> > global stats, it might help to be connected to a database that is
> > *not* the one wit
On Thu, Aug 12, 2021 at 11:32:15AM +0200, Magnus Hagander wrote:
> Which database are you connected to? If you just want to look at the
> global stats, it might help to be connected to a database that is
> *not* the one with all the tables in -- e.g. connect to "postgres" and
> query pg_stat_databa
On Thu, Aug 12, 2021 at 09:08:27AM -0400, Alvaro Herrera wrote:
> On 2021-Aug-11, hubert depesz lubaczewski wrote:
>
> > On Wed, Aug 11, 2021 at 10:16:13AM -0400, Alvaro Herrera wrote:
> > > 1. this depends on reading the stats file; that's done once per
> > > transaction. So if you run the query
On 2021-Aug-11, hubert depesz lubaczewski wrote:
> On Wed, Aug 11, 2021 at 10:16:13AM -0400, Alvaro Herrera wrote:
> > 1. this depends on reading the stats file; that's done once per
> > transaction. So if you run the query twice in a transaction, the second
> > time will take less time. You can
On Wed, Aug 11, 2021 at 6:34 PM hubert depesz lubaczewski
wrote:
>
> On Wed, Aug 11, 2021 at 10:16:13AM -0400, Alvaro Herrera wrote:
> > 1. this depends on reading the stats file; that's done once per
> > transaction. So if you run the query twice in a transaction, the second
> > time will take l
On Wed, Aug 11, 2021 at 10:16:13AM -0400, Alvaro Herrera wrote:
> 1. this depends on reading the stats file; that's done once per
> transaction. So if you run the query twice in a transaction, the second
> time will take less time. You can know how much time is spent reading
> that file by subtra
Two things,
1. this depends on reading the stats file; that's done once per
transaction. So if you run the query twice in a transaction, the second
time will take less time. You can know how much time is spent reading
that file by subtracting both times.
2. EXPLAIN (VERBOSE) will tell you which
On Wed, 11 Aug 2021 at 19:12, Vijaykumar Jain <
vijaykumarjain.git...@gmail.com> wrote:
>
>> ok my guess here was, since pg_class is updated every now and then with
> stats, it might require some lock while adding the data.
> so if it were bloated, that would block the planner to get the estimates
On Wed, 11 Aug 2021 at 18:59, hubert depesz lubaczewski
wrote:
> On Wed, Aug 11, 2021 at 06:52:15PM +0530, Vijaykumar Jain wrote:
> > Just taking a shot, as I have seen in some previous issues? Ignore is
> not
> > relevant.
> >
> > Can you run vacuum on pg_class and check the query again , or d
On Wed, Aug 11, 2021 at 06:52:15PM +0530, Vijaykumar Jain wrote:
> Just taking a shot, as I have seen in some previous issues? Ignore is not
> relevant.
>
> Can you run vacuum on pg_class and check the query again , or do you see
> pg_class bloated ?
pg_class is large, but vacuuming it didn't h
Just taking a shot, as I have seen in some previous issues? Ignore is not
relevant.
Can you run vacuum on pg_class and check the query again , or do you see
pg_class bloated ?
The other option would be gdb backtrace I think that would help.
Hi,
We have servers where there is single app db, but one that contains MANY
schema/tables.
This is on Pg 12.6.
Simple query like: select * from pg_stat_database where datname = 'app_name'
can take up to 800ms!
#v+
QUERY PLAN
13 matches
Mail list logo
