Re: [DOCS] synchronize_seqscans' description is a bit misleading - Mailing list pgsql-hackers

From Gurjeet Singh
Subject Re: [DOCS] synchronize_seqscans' description is a bit misleading
Date
Msg-id CABwTF4Vo0CypkG0hAn31tws=7yLgS9GgH9domE6wHK-zorCRLQ@mail.gmail.com
Whole thread Raw
In response to Re: [DOCS] synchronize_seqscans' description is a bit misleading  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Apr 10, 2013 at 11:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Gurjeet Singh <gurjeet@singh.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.

pgsql-hackers by date:

Previous
From: Robins Tharakan
Date:
Subject: Add regression tests for COLLATE
Next
From: Simon Riggs
Date:
Subject: Re: corrupt pages detected by enabling checksums