From: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Subject: | Re: Freeze avoidance of very large table. |
Date: | 2015-04-23 16:06:37 |
Message-ID: | 5539188D.8080205@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-04-23 16:09:21 | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |
Previous Message | Heikki Linnakangas | 2015-04-23 16:02:51 | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |