Re: [HACKERS] Cache Hash Index meta page.
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Cache Hash Index meta page. |
Дата | |
Msg-id | CA+TgmobKYsrCKe+k6wvK3sFypUiXV3it2k4aYXP9BB_jabEc4g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Cache Hash Index meta page. (Mithun Cy <mithun.cy@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Cache Hash Index meta page.
|
Список | pgsql-hackers |
Shouldn't _hash_doinsert() be using the cache, tooYes, we have an opportunity there, added same in code. But one difference is at the end at-least once we need to read the meta page to split and/or write. Performance improvement might not be as much as read-only.
I think it's probably not a good idea to cache the entire metapage. The only things that you are "really" trying to cache, I think, are hashm_maxbucket, hashm_lowmask, and hashm_highmask. The entire HashPageMetaData structure is 696 bytes on my machine, and it doesn't really make sense to copy the whole thing into memory if you only need 16 bytes of it. It could even be dangerous -- if somebody tries to rely on the cache for some other bit of data and we're not really guaranteeing that it's fresh enough for that.I'd suggest defining a new structure HashMetaDataCache with members hmc_maxbucket, hmc_lowmask, and hmc_highmask. The structure can have a comment explaining that we only care about having the data be fresh enough to test whether the bucket mapping we computed for a tuple is still correct, and that for that to be the case we only need to know whether a bucket has suffered a new split since we last refreshed the cache.It is not only hashm_maxbucket, hashm_lowmask, and hashm_highmask (3 uint32s) but we also needuint32 hashm_spares[HASH_MAX_
SPLITPOINTS], for bucket number to block mapping in "BUCKET_TO_BLKNO(metap, bucket)". Note : #define HASH_MAX_SPLITPOINTS 32, so it is (3*uint32 + 32*uint32) = 35*4 = 140 bytes.
Apart from this, there seems to be some base bug in _hash_doinsert().+ * XXX this is useless code if we are only storing hash keys.+ */
+ if (itemsz > HashMaxItemSize((Page) metap))
+ ereport(ERROR,
+ (errcode(ERRCODE_PROGRAM_
LIMIT_EXCEEDED), + errmsg("index row size %zu exceeds hash maximum %zu",
+ itemsz, HashMaxItemSize((Page) metap)),
+ errhint("Values larger than a buffer page cannot be indexed.")));
"metap" (HashMetaPage) and Page are different data structure their member types are not in sync, so should not typecast blindly as above. I think we should remove this part of the code as we only store hash keys. So I have removed same but kept the assert below as it is.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Robert HaasДата:
Сообщение: Re: [HACKERS] Creating a DSA area to provide work space for parallel execution