On Wed, Apr 10, 2013 at 11:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Gurjeet Singh <gurj...@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.
