Re: [DOCS] synchronize_seqscans' description is a bit misleading

On Wed, Apr 10, 2013 at 11:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Gurjeet Singh <gurjeet(at)singh(dot)im> writes:
> > So, again, it is not guaranteed that all the scans on a relation will
> > synchronize with each other. Hence my proposal to include the term
> > 'probability' in the definition.
>
> Yeah, it's definitely not "guaranteed" in any sense. But I don't really
> think your proposed wording is an improvement. The existing wording
> isn't promising guaranteed sync either, to my eyes.
>

Given Postgres' track record of delivering what it promises, I expect
casual readers to take that phrase as a definitive guide to what is
happening internally.

>
> Perhaps we could compromise on, say, changing "so that concurrent scans
> read the same block at about the same time" to "so that concurrent scans
> tend to read the same block at about the same time",

Given that, on first read the word "about" did not deter me from assuming
the best, I don't think adding "tend" would make much difference in a
readers (mis)understanding. Perhaps we can spare a few more words to make
more clear.

> or something like
> that. I don't mind making it sound a bit more uncertain, but I don't
> think that we need to emphasize the probability of failure.
>

I agree we don't want to stress the failure case too much, especially when
it makes the performance no worse than the absence of the feature. But we
don't want the reader to get the wrong idea either.

In addition to the slight doc improvement being suggested, perhaps a
wiki.postgresql.org entry would allow us to explain the behaviour in more
detail.

--
Gurjeet Singh

http://gurjeet.singh.im/

EnterpriseDB Inc.