Re: Seq scans status update - Mailing list pgsql-patches

From Tom Lane
Subject Re: Seq scans status update
Date
Msg-id 4329.1179424835@sss.pgh.pa.us
Whole thread Raw
In response to Re: Seq scans status update  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Seq scans status update
List pgsql-patches
Heikki Linnakangas <heikki@enterprisedb.com> writes:
> In any case, I do want this for VACUUMs to fix the "WAL flush for every
> dirty page" problem. Maybe we should indeed drop the other aspects of
> the patch and move on, I'm getting tired of this as well.

Can we devise a small patch that fixes that issue without creating
uncertain impacts on other behavior?

The thing that has made me uncomfortable with this set of patches right
along is the presumption that it's a good idea to tweak cache behavior
to improve a small set of cases.  We are using cache behavior (now
clock-sweep, formerly LRU) that is well tested and proven across a large
body of experience; my gut feeling is that deviating from that behavior
is likely to be a net loss when the big picture is considered.  I
certainly have not seen any test results that try to prove that there's
no such generalized disadvantage to these patches.

One could argue that the real bug here is that VACUUM deviates from the
standard behavior by forcing immediate recycling of pages it releases,
and that getting rid of that wart is the correct answer rather than
piling more warts atop it --- especially warts that will change the
behavior for anything besides VACUUM.

            regards, tom lane

pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: UTF8MatchText
Next
From: Andrew Dunstan
Date:
Subject: Re: UTF8MatchText