Re: Proposal : For Auto-Prewarm.

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Proposal : For Auto-Prewarm.
Date: 2016-12-02 12:14:07
Message-ID: CAJrrPGeZz8X7kqBGUJamWuk3LSx23fwHTO2LcT=+vMVnrtyFLg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 29, 2016 at 4:26 PM, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>
wrote:

> Sorry I took some time on this please find latest patch with addressed
> review comments. Apart from fixes for comments I have introduced a new GUC
> variable for the pg_autoprewarm "buff_dump_interval". So now we dump the
> buffer pool metadata at every buff_dump_interval secs. Currently
> buff_dump_interval can be set only at startup time. I did not choose to do
> the dumping at checkpoint time, as it appeared these 2 things are not much
> related and keeping it independent would be nice for usage. Also overhead
> of any communication between them can be avoided.
>
> On Fri, Oct 28, 2016 at 1:45 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
> wrote:
> > IMO it would be better to add this functionality to pg_prewarm instead
> of creating another contrib module. That would reduce confusion and reduce
> > the amount of code necessary.
>
> I have merged pg_autoprewarm module into pg_prewarm, This is just the
> directory merge, Functionality merge is not possible pg_prewarm is just a
> utility function with specific signature to load a specific relation at
> runtime, where as pg_autoprewarm is a bgworker which dumps current buffer
> pool and load it during startup time.
>
> > Presumably the first 4 numbers will vary far less than blocknum, so it's
> probably worth reversing the order here (or at least put blocknum first).
>
> function sort_cmp_func is for qsort so orderly comparison is needed to say
> which is bigger or smaller, If we put blocknum first, we cannot decide same.
>
> > AFAICT this isn't necessary since palloc will error itself if it fails.
>
> Fixed.
>
> > Since there's no method to change DEFAULT_DUMP_FILENAME, I would call it
> what it is: DUMP_FILENAME.
>
> Fixed.
>
> > Also, maybe worth an assert to make sure there was enough room for the
> complete filename. That'd need to be a real check if this was configurable
> > anyway.
>
> I think if we make it configurable I think I can put that check.
>
> > + if (!avoid_dumping)
> > + dump_now();
> > Perhaps that check should be moved into dump_now() itself...
>
> Fixed.
>
>
Moved to next CF with "needs review" status.

Regards,
Hari Babu
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2016-12-02 12:18:49 Re: Proposal: scan key push down to heap [WIP]
Previous Message Haribabu Kommi 2016-12-02 12:12:38 Re: Supporting huge pages on Windows