From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | pgsql-patches(at)postgresql(dot)org |
Subject: | synchronized scan: reset state at end of scan |
Date: | 2008-06-01 00:45:14 |
Message-ID: | 1212281114.6360.22.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
syncscan-reset.diff | text/x-patch | 4.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-06-01 02:01:26 | Re: synchronized scan: reset state at end of scan |
Previous Message | Zdenek Kotala | 2008-05-30 16:16:09 | partial header cleanup |