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:
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
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 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
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 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
