Re: [HACKERS] Cached plans and statement generalization

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: [HACKERS] Cached plans and statement generalization
Дата
Msg-id CA+q6zcW4bL=pr3_YjkKtVhHUN5qfd7kxTFUWqCiavA0ROjBu0Q@mail.gmail.com
обсуждение исходный текст
Ответ на RE: [HACKERS] Cached plans and statement generalization  ("Yamaji, Ryo" <yamaji.ryo@jp.fujitsu.com>)
Ответы RE: [HACKERS] Cached plans and statement generalization  ("Yamaji, Ryo" <yamaji.ryo@jp.fujitsu.com>)
Список pgsql-hackers
> On Fri, Sep 28, 2018 at 10:46 AM Yamaji, Ryo <yamaji.ryo@jp.fujitsu.com> wrote:
>
> On Tuesday, August 7, 2018 at 0:36 AM, Konstantin Knizhnik wrote:
>
> > I have registered the patch for next commitfest.
> > For some reasons it doesn't find the latest autoprepare-10.patch and still
> > refer to autoprepare-6.patch as the latest attachement.
>
> I'm sorry for the late reply. I'm currently reviewing autoprepare.
> I could not make it in time for the commit fests in September,
> but I will continue to review for the next commitfest.
>
> Performance tests are good results. The results are shown below.
> pgbench -s 100 -c 8 -t 10000 -S (average of 3 trials)
> - all autoprepare statements use same memory context.
>     18052.22706 TPS
> - each autoprepare statement use separate memory context.
>     18607.95889 TPS
> - calculate memory usage (autoprepare_memory_limit)
>     19171.60457 TPS
>
> From the above results, I think that adding/changing functions
> will not affect performance. I am currently checking the behavior
> when autoprepare_memory_limit is specified.

Hi,

Thanks for reviewing. Since another CF is about to end, maybe you can post the
full review feedback?

> On Tue, Jul 31, 2018 at 11:30 PM Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote:
>
> Concerning next commit fest - I am not sure.
> At previous commitfest it was returned with feedback that it "has
> received no review or comments since last May".
> May be your review will help to change this situation.

Well, I think that wasn't the only reason, and having some balance here would
be nice. Anyway, thanks for working on this patch!

Unfortunately, the patch needs to be rebased one more time. Also, I see there
were concerns about how reliable this patch is. Just out of curiosity, can you
tell now that from v4 to v11 reliability is not a concern anymore?

(If you don't mind, I'll also CC some of the reviewers who saw previous
versions).


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Python versions (was Re: RHEL 8.0 build)
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: Implementing SQL ASSERTION