Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: andres(at)anarazel(dot)de
Cc: dgrowleyml(at)gmail(dot)com, pg(at)bowt(dot)ie, pgsql-hackers(at)postgresql(dot)org, n(dot)gluhov(at)postgrespro(dot)ru, andrew(at)dunslane(dot)net
Subject: Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
Date: 2022-06-17 07:05:56
Message-ID: 20220617.160556.1675573261676681263.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Fri, 17 Jun 2022 15:59:26 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> At Fri, 17 Jun 2022 15:54:13 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> > > Or we could add a timeout.c API that specifies the timeout?
> >
> > I sometimes wanted this, But I don't see a simple way to sort multiple
> > relative timeouts in absolute time order. Maybe we can skip
> > GetCurrentTimestamp only when inserting the first timeout, but I don't
> > think it benefits this case.
>
> Or we can use a free-run interval timer and individual down-counter
> for each timtouts. I think we need at-most 0.1s resolution and error
> of long-run timer doesn't harm?

Yeah, stupid. We don't want awake process with such a high frequency..

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message wangw.fnst@fujitsu.com 2022-06-17 07:17:10 RE: Perform streaming logical transactions by background workers and parallel apply
Previous Message Peter Eisentraut 2022-06-17 07:01:42 Re: Typo in ro.po file?