synchronized scan: reset state at end of scan

Started by Jeff Davisabout 18 years ago3 messagespatches
Jump to latest
#1Jeff Davis
pgsql@j-davis.com

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
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jeff Davis (#1)
Re: synchronized scan: reset state at end of scan

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

#3Jeff Davis
pgsql@j-davis.com
In reply to: Tom Lane (#2)
Re: synchronized scan: reset state at end of scan

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