From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | nathandbossart(at)gmail(dot)com |
Cc: | schnjere(at)amazon(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: identifying the backend that owns a temporary schema |
Date: | 2022-08-23 09:19:37 |
Message-ID: | 20220823.181937.499485293703289968.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Tue, 16 Aug 2022 16:04:23 -0700, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote in
> On Mon, Aug 15, 2022 at 02:47:25PM -0700, Jeremy Schneider wrote:
> > I'll take a look at the patch if I can... and I'm hopeful that we're
> > able to move this idea forward and get this little gap in PG filled once
> > and for all!
>
> Thanks!
>
> I noticed that the "result" variable in pg_stat_get_backend_idset() is kind
> of pointless after my patch is applied, so here is a v2 with it removed.
It seems to be a sensible way to expose the PGPROC backend ids to SQL
interface. It inserts bsearch into relatively frequently-called
function but (I believe) that doesn't seem to matter much (comparing
to, for example, the size of id->position translation table).
I don't think pgstat_fetch_stat_beentry needs to check for
out-of-range ids anymore. That case is a kind of rare and bsearch
properly handles it.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2022-08-23 09:26:29 | Re: Asynchronous execution support for Custom Scan |
Previous Message | David Rowley | 2022-08-23 09:03:52 | Re: Reducing the chunk header sizes on all memory context types |