Re: Some other things about contrib/bloom and generic_xlog.c
От | Tom Lane |
---|---|
Тема | Re: Some other things about contrib/bloom and generic_xlog.c |
Дата | |
Msg-id | 19258.1460385417@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Some other things about contrib/bloom and generic_xlog.c (Teodor Sigaev <teodor@sigaev.ru>) |
Список | pgsql-hackers |
Teodor Sigaev <teodor@sigaev.ru> writes: >> 2. Unless I'm missing something, contrib/bloom is making no effort >> to ensure that bloom index pages can be distinguished from other pages >> by pg_filedump. That's fine if your expectation is that bloom will always >> be a toy with no use in production; but otherwise, not so much. You need >> to make sure that the last two bytes of the page special space contain a >> uniquely identifiable code; compare spgist_page_id in SPGiST indexes. > Now contrib/bloom is a canonical example how to implement yourown index and how > to use generic WAL interface. And it is an useful toy: in some cases it could > help in production system, patch attached. I'm a little dissatisfied with patch > because I had to add unused field to BloomPageOpaqueData, in opposite case size > of BloomPageOpaqueData struct equals 6 bytes but special size is MAXALIGNED, so, > last two bytes will be unused. If unused field is not a problem, I will push > this patch. Yes, it will mean that the special space will have to be 8 bytes not 4. But on the other hand, that only makes a difference on 32-bit machines; if MAXALIGN is 8 then you won't be able to fit anything into those bytes anyway. And someday there might be a use for the other two bytes ... so I'm not particularly concerned by the "wasted space" argument. regards, tom lane
В списке pgsql-hackers по дате отправления: