Re: Limiting setting of hint bits by read-only queries; vacuum_delay

On 25 March 2013 02:50, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> On 3/24/13 7:14 AM, Simon Riggs wrote:
>>
>> Patch to implement is a few hours work. The only complexity is
>> deciding how to handle SQL in functions.... to which I would say, as
>> simply as possible.
>
>
> Like the Page replacement ideas, the throttle on how fast something like
> this will get done depends not on development time, but on putting together
> more performance regression tests.

I don't see any role for regression tests there, nor even performance
tests. This isn't vague discussion about page replacement.

There's absolutely zero point spending time on how background tasks
might work while the foreground tasks continue to do the work right in
front of our eyes. Until we agree how to limit what foreground tasks
do, we'll never move forwards.

> The idea I was thinking about is
> refactoring the background writer's role in hint bit maintenance. If
> backends could push "this looks dirty" page numbers toward the BGW and keep
> going, it might stream those out to disk under its control.

> I also have a larger proposal for how to refactor I/O so that both queries
> and CREATE INDEX have similar cost controls to the ones used to limit
> vacuum. And two more based on collecting extra data for high cost queries
> before they run.
>
> But right now I keep biting my tongue about the design on all these, and
> return to working on one of the patches already in the CF queue instead.

This is related to one of the patches in this CF, hence why I bring it up now.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services