On 23/04/15 17:45, Bruce Momjian wrote:
On Thu, Apr 23, 2015 at 09:45:38AM -0400, Robert Haas wrote:
Right. My point is that either you do X 2M times to maintain that fork
and the overhead of the file existence, or you do one VACUUM FREEZE. I
am saying that 2M is a large number and adding all those X's might
exceed the cost of a VACUUM FREEZE.
I agree, but if we instead make this part of the visibility map
instead of a separate fork, the cost is much less. It won't be any
more expensive to clear 2 consecutive bits any time a page is touched
than it is to clear 1. The VM fork will be twice as large, but still
tiny. And the fact that you'll have only half as many pages mapping
to the same VM page may even improve performance in some cases by
reducing contention. Even when it reduces performance, I think the
impact will be so tiny as not to be worth caring about.
Agreed, no extra file, and the same write volume as currently. It would
also match pg_clog, which uses two bits per transaction --- maybe we can
reuse some of that code.
Yeah, this approach seems promising. We probably can't reuse code from
clog because the usage pattern is different (key for clog is xid, while
for visibility/freeze map ctid is used). But visibility map storage
layer is pretty simple so it should be easy to extend it for this use.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
