Re: Turning off HOT/Cleanup sometimes

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(dot)riggs(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Turning off HOT/Cleanup sometimes
Date: 2015-04-22 17:59:35
Message-ID: 5537E187.8010005@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/22/15 11:37 AM, Jim Nasby wrote:
> On 4/21/15 4:07 PM, Peter Eisentraut wrote:
>> On 4/21/15 4:45 PM, Jim Nasby wrote:
>> In order for a background worker to keep up with some of the workloads
>> that have been presented as counterexamples, you'd need multiple
>> background workers operating in parallel and preferring to work on
>> certain parts of a table. That would require a lot more sophisticated
>> job management than we currently have for, say, autovacuum.
>
> My thought was that the foreground queries would send page IDs to the
> bgworker via a shmq. If the queries have to do much waiting at all on IO
> then I'd expect the bgworker to be able to keep pace with a bunch of
> them since it's just grabbing buffers that are already in the pool (and
> only those in the pool; it wouldn't make sense for it to pull it back
> from the kernel, let alone disk).
>
> We'd need to code this so that if a queue fills up the query doesn't
> block; we just skip that opportunity to prune. I think that'd be fine.

I think a "to-clean-up map" would work better. But basically we need a
way to remember where to clean up later if we're not going to do it in
the foreground.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Payal Singh 2015-04-22 18:04:42 Re: Idea: closing the loop for "pg_ctl reload"
Previous Message Jan de Visser 2015-04-22 17:43:26 Re: Improve sleep processing of pg_rewind TAP tests