From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Trivial patch to double vacuum speed on tables with no indexes |
Date: | 2006-09-04 22:01:32 |
Message-ID: | 87bqpvi94z.fsf@stark.enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > Patch applied. Thanks.
>>
>> Wait a minute. This patch changes the behavior so that
>> LockBufferForCleanup is applied to *every* heap page, not only the ones
>> where there are removable tuples. It's not hard to imagine scenarios
>> where that results in severe system-wide performance degradation.
>> Has there been any real-world testing of this idea?
>
> I see the no-index case now:
>
> + if (nindexes)
> + LockBuffer(buf, BUFFER_LOCK_SHARE);
> + else
> + LockBufferForCleanup(buf);
>
> Let's see what Greg says, or revert.
Hm, that's a good point. I could return it to the original method where it
released the share lock and did he LockBufferForCleanup only if necessary. I
thought it was awkward to acquire a lock then release it to acquire a
different lock on the same buffer but it's true that it doesn't always have to
acquire the second lock.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2006-09-04 22:04:24 | Re: Information schema - finalize key_column_usage |
Previous Message | Bruce Momjian | 2006-09-04 21:47:51 | Re: setseed() doc |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2006-09-04 22:04:24 | Re: Information schema - finalize key_column_usage |
Previous Message | Bruce Momjian | 2006-09-04 21:47:51 | Re: setseed() doc |