From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | "huangning290(at)yahoo(dot)com" <huangning290(at)yahoo(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: GIN index |
Date: | 2022-01-25 15:33:19 |
Message-ID: | 20220125153319.bw3hsdm5epfkm2j6@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
On Tue, Jan 25, 2022 at 02:42:14AM +0000, huangning290(at)yahoo(dot)com wrote:
> Hi:I created a new variable-length data type, and now I want to create a GIN
> index for it. According to the rules of GIN index, I created three functions:
> extractValue, extractQuery, and compare. I made sure that the return value of
> the first two functions is the address of the array, but when using the index
> query, the GIN tuple data obtained by calling PG_GETARG_DATUM in the compare
> function is incorrect, and it is misplaced! In memory the size of the data
> header becomes something else, and the position of the first byte is not the
> header, it becomes the fourth byte. So there is a high probability that the
> function called is wrong or my return value is wrong when creating the index
> or the error is somewhere else?
It's hard to have an opinion without seeing any code extract. Have you checked
contrib module for examples of other GIN opclasses, like pg_trgrm, or hstore
for varlena datatype with GIN support?
Note also that pgsql-hackers is probably a better mailing list for this kind of
questions.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Dearman | 2022-01-25 16:09:39 | Re: tstzrange on large table gives poor estimate of expected rows |
Previous Message | Ray O'Donnell | 2022-01-25 14:26:44 | Re: Robust ways for checking allowed values in a column |