Re: Patch: ResourceOwner optimization for tables with many partitions
От | Aleksander Alekseev |
---|---|
Тема | Re: Patch: ResourceOwner optimization for tables with many partitions |
Дата | |
Msg-id | 20151211125457.21791078@fujitsu обсуждение исходный текст |
Ответ на | Re: Patch: ResourceOwner optimization for tables with many partitions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Patch: ResourceOwner optimization for tables with
many partitions
|
Список | 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
В списке pgsql-hackers по дате отправления: