On ���, 13 ��� 2000, Tom Lane wrote:
> Denis Perchine <dyp@perchine.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.
No... You did not get me. I am talking about completly different thing:
I strace'ed postgres binary when doing queries and found out that it
do lseek after each read, and the difference in the position is 8096.
It means that we are in correct position anyway and do not need additional lseek.
--
Sincerely Yours,
Denis Perchine
----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------
