synchronized scan: reset state at end of scan
От | Jeff Davis |
---|---|
Тема | synchronized scan: reset state at end of scan |
Дата | |
Msg-id | 1212281114.6360.22.camel@jdavis обсуждение исходный текст |
Ответы |
Re: synchronized scan: reset state at end of scan
|
Список | 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
Вложения
В списке pgsql-patches по дате отправления: