synchronized scan: reset state at end of scan
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
Attachments:
syncscan-reset.difftext/x-patch; charset=UTF-8; name=syncscan-reset.diffDownload+65-0
Jeff Davis <pgsql@j-davis.com> writes:
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
I thought the end conclusion of that thread was to not do anything,
on the grounds that
(1) having new scans sometimes fail to join an existing syncscan
herd would be a bad thing because of the resulting performance
uncertainty;
(2) partially masking the order-nondeterminism created by syncscans
would be a bad thing because it would make it more likely for people
to not notice the issue during testing.
regards, tom lane
On Sat, 2008-05-31 at 22:01 -0400, Tom Lane wrote:
I thought the end conclusion of that thread was to not do anything,
on the grounds that
(1) having new scans sometimes fail to join an existing syncscan
herd would be a bad thing because of the resulting performance
uncertainty;
(2) partially masking the order-nondeterminism created by syncscans
would be a bad thing because it would make it more likely for people
to not notice the issue during testing.
Ok, I certainly am not pushing for this patch to be applied. I'll
consider it closed.
Regards,
Jeff Davis