Re: Fastpath while arranging the changes in LSN order in logical decoding

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: Fastpath while arranging the changes in LSN order in logical decoding
Дата
Msg-id CAFiTN-sytOTjsnFGMfbfF0ZGnACmPYmzYpY2G6DJ8NY0nUcgag@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fastpath while arranging the changes in LSN order in logical decoding  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Fastpath while arranging the changes in LSN order in logical decoding  (James Coleman <jtc331@gmail.com>)
Re: Fastpath while arranging the changes in LSN order in logicaldecoding  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Sat, Mar 7, 2020 at 9:59 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Sat, Mar 7, 2020 at 12:30 AM Andres Freund <andres@anarazel.de> wrote:
> >
> > Hi,
> >
> > On 2020-01-08 18:06:52 +0530, Dilip Kumar wrote:
> > > On Wed, 8 Jan 2020 at 5:28 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > >
> > > > On 25/11/2019 05:52, Dilip Kumar wrote:
> > > > > In logical decoding, while sending the changes to the output plugin we
> > > > > need to arrange them in the LSN order.  But, if there is only one
> > > > > transaction which is a very common case then we can avoid building the
> > > > > binary heap.  A small patch is attached for the same.
> > > >
> > > > Does this make any measurable performance difference? Building a
> > > > one-element binary heap seems pretty cheap.
> > >
> > >
> > > I haven’t really measured the performance for this.  I will try to do that
> > > next week.  Thanks for looking into this.
> >
> > Did you do that?
>
> I tried once in my local machine but could not produce consistent
> results.  I will try this once again in the performance machine and
> report back.

I have tried to decode changes for the 100,000 small transactions and
measured the time with head vs patch.  I did not observe any
significant gain.

Head
-------
519ms
500ms
487ms
501ms

patch
------
501ms
492ms
486ms
489ms

IMHO, if we conclude that because there is no performance gain so we
don't want to add one extra path in the code then we might want to
remove that TODO from the code so that we don't spend time for
optimizing this in the future.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Add an optional timeout clause to isolationtester step.