From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: postgres_fdw batching vs. (re)creating the tuple slots |
Date: | 2021-05-30 21:26:16 |
Message-ID: | 20210530212616.5k5nxnbunwnwet2a@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-05-30 17:10:59 -0400, Tom Lane wrote:
> But it does seem like the hashing scheme somebody added to resowners
> is a bit too simplistic. It ought to be able to cope with lots of
> refs to the same object, or at least not be extra-awful for that case.
It's not really the hashing that's the problem, right? The array
representation would have nearly the same problem, I think?
It doesn't seem trivial to improve it without making resowner.c's
representation a good bit more complicated. Right now there's no space
to store a 'per resowner & tupdesc refcount'. We can't even just make
the tuple desc reference a separate allocation (of (tupdesc, refcount)),
because ResourceArrayRemove() relies on testing for equality with ==.
I think we'd basically need an additional version of ResourceArray (type
+ functions) which can store some additional data for each entry?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-05-30 21:34:19 | Re: storing an explicit nonce |
Previous Message | Tom Lane | 2021-05-30 21:10:59 | Re: postgres_fdw batching vs. (re)creating the tuple slots |