On 1/7/2024 17:58, James Pang wrote:
we have a daily job to do vacuumdb including catalog tables, and
in same database , I did similar query with where=pk on another table
and shared buffer access is very small, if catalog table bloat, should
see similar shared buffer access when plannin
we have a daily job to do vacuumdb including catalog tables, and in
same database , I did similar query with where=pk on another table and
shared buffer access is very small, if catalog table bloat, should see
similar shared buffer access when planning for other tables ,right? How to
get mor
On Mon, 1 Jul 2024 at 22:20, Pavel Stehule wrote:
> The planners get min/max range from indexes. So some user's indexes can be
> bloated too with similar effect
I considered that, but it doesn't apply to this query as there are no
range quals.
David
Hi
po 1. 7. 2024 v 12:10 odesílatel David Rowley napsal:
> On Mon, 1 Jul 2024 at 21:45, James Pang wrote:
> >Buffers: shared hit=110246 <<< here planning need access a
> lot of buffers
> > Planning Time: 81.850 ms
> > Execution Time: 0.034 ms
> >
> >could you help why planning
On Mon, 1 Jul 2024 at 21:45, James Pang wrote:
>Buffers: shared hit=110246 <<< here planning need access a lot of
> buffers
> Planning Time: 81.850 ms
> Execution Time: 0.034 ms
>
>could you help why planning need a lot of shared buffers access ?
Perhaps you have lots of bloat
Hi,
a simple SQL "select ... from tablex where id1=34215670 and
id2=59403938282;
id1 and i2 are bigint and primary key.
Index Cond: ((tablex.id2 = ' 5940393828299'::bigint) AND (tablex.id1
= ' 34215670 '::bigint))
Buffers: shared hit=2
Query Identifier: -1350604566224020319
Planning:
