Re: Lots of read activity on index only scan

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Lots of read activity on index only scan
Date: 2022-11-18 23:13:23
Message-ID: CAH2-WznGqXxUO-wGU9tsHfcvO4AhbQHdM39W6tkuTEknYHCgqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Nov 18, 2022 at 1:50 PM Peter J. Holzer <hjp-pgsql(at)hjp(dot)at> wrote:
> There should be about 27000 of them, same as for the othe index, right?

There aren't that many. The point I'm making is that you can access
each VM page approximately once (and check relatively many index
tuple's TIDs all in one go), or many times. The total number of VM
pages may be constant, but the access patterns are quite different
owing to differences in how the data is clustered in each index.

> > When there is naturally a high correlation (or some kind of
> > clustering) in how we access VM pages, we'll naturally be able to do
> > more visibility checks covering more index tuples per VM page
> > accessed.
>
> So you are saying that these are accesses to the visibility map, not the
> base table?

Yes. I see "Heap Fetches: 0" for both plans, that each query the same
table and scan approximately the same number of index pages. So VM
accesses are the only explanation that makes any sense.

> > Also worth bearing in mind that it's unusual to have a perfectly
> > random and uniformly distributed clustering of index tuples,
>
> Sure. This is a highly contrived example.

FWIW I think that it could be a lot less bad, even with indexes that
you'd think would be almost as bad as the bad one from your test case.
Even things that appear to be random aren't usually nearly as random
as what you've shown.

--
Peter Geoghegan

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Brad White 2022-11-19 00:05:36 Re: Upgrading to v12
Previous Message Ron 2022-11-18 22:21:18 Re: Seeking practice recommendation: is there ever a use case to have two or more superusers?