synchronized scan: reset state at end of scan - Mailing list pgsql-patches

From Jeff Davis
Subject synchronized scan: reset state at end of scan
Date
Msg-id 1212281114.6360.22.camel@jdavis
Whole thread Raw
Responses Re: synchronized scan: reset state at end of scan
List pgsql-patches
I was looking into supporting synchronized scans for VACUUM, and I
noticed that we currently don't remove the reported scan location as
this post suggests:

http://archives.postgresql.org/pgsql-patches/2007-06/msg00047.php

There was some debate about whether it should be done, but I thought
that the solution here seemed to satisfy most people's concerns:

http://archives.postgresql.org/pgsql-patches/2007-06/msg00052.php

I attached a patch that implements the above idea.

The benefit is that if you have a singular scan, it will start at the
beginning of the heap and not at some arbitrary place.

The cost is that it's not 100% guaranteed that the location entry will
be removed. The backend that started the scan could abort, die, etc.
Also, in rare situations there is a small window created where a new
scan might not be synchronized with existing concurrent scans. This is
really only an issue when issuing queries with limits or issuing two
scans that progress at different rates. I think it's somewhat reasonable
to say that if you're doing either of those things, you shouldn't be too
surprised if it messes with synchronized scanning. I have more
information in the comments in the attached patch.

I do not have a strong opinion about whether this patch is applied or
not. I am submitting this just for the sake of completeness.

Regards,
    Jeff Davis

Attachment

pgsql-patches by date:

Previous
From: Teodor Sigaev
Date:
Subject: GIN improvements
Next
From: Tom Lane
Date:
Subject: Re: synchronized scan: reset state at end of scan