From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: heap vacuum & cleanup locks |
Date: | 2011-06-07 19:24:07 |
Message-ID: | BANLkTikbLZb3NyUHJHpx4kbYdaoR9+2m0Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 503 스포츠 토토 결과 |
On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> But I think you've hit the important point here. The problem is not
> whether VACUUM waits for the pin, its that the pins can be held for
> extended periods.
Yes
> It makes more sense to try to limit pin hold times than it does to
> come up with pin avoidance techniques.
Well it's super-exclusive-vacuum-lock avoidance techniques. Why
shouldn't it make more sense to try to reduce the frequency and impact
of the single-purpose outlier in a non-critical-path instead of
burdening every other data reader with extra overhead?
I think Robert's plan is exactly right though I would phrase it
differently. We should get the exclusive lock, freeze/kill any xids
and line pointers, then if the pin-count is 1 do the compaction.
I'm really wishing we had more bits in the vm. It looks like we could use:
- contains not-all-visible tuples
- contains not-frozen xids
- in need of compaction
I'm sure we could find a use for one more page-level vm bit too.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-07 19:24:53 | Re: BUG #6041: Unlogged table was created bad in slave node |
Previous Message | Tom Lane | 2011-06-07 18:55:49 | Re: reducing the overhead of frequent table locks - now, with WIP patch |