Re: Caching number of blocks in relation to avoi lseek.

Denis Perchine <dyp(at)perchine(dot)com> writes:
> And what about skipping lseek when continually read relation?
> Is it possible?

In a pure read scenario the way it's supposed to work is that an
lseek(END) is done once at the start of each sequential scan, and we
save that value in rd_nblocks. Then we read rd_nblocks pages and stop.
By the time we finish the scan there might be more pages in the relation
(added by other backends, or even by ourselves if it's an update query).
But those pages cannot contain any tuples that could be visible to the
current scan, so it's OK if we don't read them. However, we do need a
new lseek() --- or some other way to verify the right table length
--- at least once per transaction start or CommandCounterIncrement.
Either of those events could make new tuples visible to us.

I think there may be some code paths that cause us to do more than just
one lseek(END) during scan startup, and if so it'd be worthwhile to try
to get rid of the extra lseeks(). But you'd have to be careful that
you didn't remove any lseeks that are essential in some other paths.

regards, tom lane