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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fastpath while arranging the changes in LSN order in logical decoding
Date: 2020-03-24 12:46:28
Message-ID: CAA4eK1+fr6=0V6+jCp_KgNrHhy=731RNe3waMKUsnuKQTk7qGA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 9, 2020 at 11:07 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> On 2020-03-07 11:15:27 +0530, Dilip Kumar wrote:
> > 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.
>
> +1
>

Dilip, are you planning to do more tests for this? Anyone else wants
to do more tests? If not, based on current results, we can remove that
TODO and in future, if someone comes with a test case to show benefit
for adding fastpath, then we can consider the patch proposed by Dilip.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-03-24 12:47:30 Re: error context for vacuum to include block number
Previous Message Amit Kapila 2020-03-24 12:38:29 Re: Improve checking for pg_index.xmin