On Fri, Apr 4, 2014 at 1:19 PM, Tom Lane wrote:
> Joshua Yanovski 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 ha
On 04 April 2014 18:09, Joshua Yanovski Wrote:
> The counter would be updated only by VACUUM, which would perform the
> same computation performed by the COUNT operation but add it
> permanently to counter just before it set the visible_map bit to 1 (I
> am not certain whether this would requir
Yeah, you're right, I believe that every code path in VACUUM that
leads to the visibility map bit being set also leads to all remaining
tuples on the page being frozen. So in a world without heap pruning,
frozen should be a reliable proxy for "value of the tuple the last
time it was added to the
Joshua Yanovski 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 t
> VACUUM counter updates, on the other hand, initially seem more
> problematic, since if we grab the value of the counter, then VACUUM
> updates the counter and the visbility bits, and then we check which
> visibility bits are set, we might skip pages we really need to check
> (since we're using an
t> It seems to me this can't possibly work because of race conditions.
> In particular, what happens when some query dirties a page and thereby
> clears its fully-visible bit? Presumably, any such query would have
> to (1) recompute the number of all-visible rows on that page (already
> an expens
Joshua Yanovski writes:
> Essentially, the idea is that you would store a counter (let's say, as
> a special index type) that would initially (on index creation) be set
> to the total count of
> all rows on fully visible pages (visibility map bit set to 1).
It seems to me this can't possibly work
>From feedback on IRC, two immediately obvious technical problems:
* Heap pruning can happen at any time, not just during VACUUM and HOT
updates. This is obviously a pretty significant issue and I doubt the
easy solution (don't do heap pruning for tables with an index like
this) would be acceptab
Hey all,
First off, please feel free to let me know if this idea is a waste of time :)
I was thinking about COUNT(*) and its slow performance today, and I
thought about whether we could get better performance by taking a page
out of index-only-scans.
Essentially, the idea is that you would store
