Re: Proposal: COUNT(*) (and related) speedup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: COUNT(*) (and related) speedup
Date
Msg-id 20929.1396631979@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: COUNT(*) (and related) speedup  (Joshua Yanovski <pythonesque@gmail.com>)
Responses Re: Proposal: COUNT(*) (and related) speedup
Re: Proposal: COUNT(*) (and related) speedup
List pgsql-hackers
Joshua Yanovski <pythonesque@gmail.com> writes:
>> But worse, what happens if a count(*)
>> is in progress?  It might or might not have scanned this page already,
>> and there's no way to get the right answer in both cases.  Counter
>> updates done by VACUUM would have a similar race-condition problem.

> I don't think the first part really matters.  If the page was visible
> when COUNT(*) started and then got dirtied by some other transaction,
> any changes by the second transaction shouldn't alter the actual count
> in our transaction anyway, so whether we scan the page needlessly or
> not seems beside the point.

The question is not whether you scan a page "needlessly" or not, it's
whether you double-count the tuples on it.  I don't think it's possible to
be sure that when you add the central counter value into your local sum,
you are neither double-counting nor omitting pages whose all-visible state
changed while you were scanning the table.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Using indices for UNION.
Next
From: Tom Lane
Date:
Subject: Another thought about search_path semantics