Patch applied. Thanks.
---
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes
Bruce Momjian [EMAIL PROTECTED] 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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.
Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes would be
needed (eg, there's no need to eat maintenance_work_mem worth of RAM
for the dead-TIDs array); and a decent respect to
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes would be
needed (eg, there's no need to eat maintenance_work_mem worth of RAM
for the dead-TIDs
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
How often does that case come up in the real world, for tables that are
large enough that you'd care about vacuum performance?
I would have had the same objection if it resulted in substantially more
complex code but
