Re: Proposal: COUNT(*) (and related) speedup

From: Joshua Yanovski <pythonesque(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: COUNT(*) (and related) speedup
Date: 2014-04-04 17:10:43
Message-ID: CABz-M-G8y2zW+7+m99WATWL6FnzpcctVFior-84eQWFbarHjhA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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 old value for the counter). But in practice I
> am pretty sure this is a nonissue, because as long as our COUNT(*)
> transaction is going, no pages can have their visibility bits marked
> unless they haven't been updated since the transaction started, which
> consequently means we won't see the counter updated (the counter is
> intended to be updated immediately before the visibility bit is set
> while VACUUMing). Took me a while to figure this out, for thanks for
> pointing it out :)

Clarification: the counter may be updated, but never in a way that
affects the final result, because it can only be updated to reflect
statistics on pages that are fully visible to all current
transactions. As long as we scan every page that was "really" dirty
at the start of our transactions, we can't really go wrong, since we
can recompute that information ourselves--we can just be better or
worse at avoiding redundant heap fetches.

--
Josh

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-04 17:14:38 Re: Using indices for UNION.
Previous Message Robert Haas 2014-04-04 16:55:14 Re: GSoC proposal - "make an unlogged table logged"