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
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" |