| From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Lock problem with autovacuum truncating heap |
| Date: | 2011-03-28 16:35:21 |
| Message-ID: | 4D90B8C9.3080902@Yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 3/27/2011 10:43 PM, Tom Lane wrote:
> In particular, I thought the direction Jan was headed was to release and
> reacquire the lock between truncating off limited-size chunks of the
> file. If we do that, we probably *don't* want or need to allow autovac
> to be booted off the lock more quickly.
That is correct.
>> 3) Scanning backwards 8MB at a time scanning each 8MB forwards instead
>> of just going back by block backwards.
>
> Maybe. I'd want to see some experimental evidence justifying the choice
> of chunk size; I'm pretty sure this will become counterproductive once
> the chunk size is too large.
Me too, which is why that part of my proposal is highly questionable and
requires a lot of evidence to be even remotely considered for back releases.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2011-03-28 17:13:16 | Re: Additional options for Sync Replication |
| Previous Message | Jan Wieck | 2011-03-28 16:17:54 | Re: Lock problem with autovacuum truncating heap |