From: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch: ResourceOwner optimization for tables with many partitions |
Date: | 2015-12-11 09:54:57 |
Message-ID: | 20151211125457.21791078@fujitsu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> To be honest, I think this patch is really ugly. [...] I'm not sure
>> exactly what to do about that, but it seems like a problem.
I have an idea. There are actually two types of resources - int-like
(buffers, files) and void*-like (RelationRef, TupleDesc, ...). What if
I split ResourceArray into IntResourceArray and PointerResourceArray? It
would definitely solve ugliness problem --- no more memcpy's, char[]
buffers, etc.
>> It would be advisable for example that hash_any not suddenly become
>> covered by the "must not fail" requirement.
Frankly I can't think of any case when hash_any could or should fail.
Maybe we should just add a "must not fail" constraint to hash_any
description?
Also I could use some other hash implementation. It may be reasonable
in this case since size of data I would like to hash is small and known
in advance.
>> BTW, I do not think you can get away with the requirement that
>> all-zeroes isn't a valid resource representation. It might be okay
>> today but it's hardly future-proof.
Agree. I could store a value that should be considered as "zero" in
ResourceArray. It would be InvalidBuffer for buffers, -1 for files and
NULL for all void*-types. Does such solution sounds OK?
Best regards,
Aleksander
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2015-12-11 10:07:43 | Re: Patch: ResourceOwner optimization for tables with many partitions |
Previous Message | Etsuro Fujita | 2015-12-11 09:48:45 | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) |