Re: [HACKERS] makesign() broken in tsearch2
the bottom half might be messed up too. So we are failing to exploit the full intended sign space, which presumably is costing something in index efficiency. You are absolutly right. My fault. It looks to me like the values calculated by this routine end up on disk, and therefore we can't fix it without forcing an initdb, or at least REINDEX of all affected indexes. Is that correct? No. query_gist.c exists only in HEAD branch. That code is devloped not a lot time ago, and itsn't tested well yet. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] makesign() broken in tsearch2
Teodor Sigaev [EMAIL PROTECTED] writes: It looks to me like the values calculated by this routine end up on disk, and therefore we can't fix it without forcing an initdb, or at least REINDEX of all affected indexes. Is that correct? No. query_gist.c exists only in HEAD branch. Oh, good, that makes it easy. Do you want to apply the fix or shall I? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] makesign() broken in tsearch2
Oh, good, that makes it easy. Do you want to apply the fix or shall I? I will have normal access to Internet only on Monday. It can easy wait for me :) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] makesign() broken in tsearch2
I noticed the following code in tsearch2: typedef uint64 TPQTGist; static TPQTGist makesign(QUERYTYPE * a) { int i; ITEM *ptr = GETQUERY(a); TPQTGistsign = 0; for (i = 0; i a-size; i++) { if (ptr-type == VAL) sign |= 1 (ptr-val % SIGLEN); ptr++; } return sign; } This is wrong because 1 is an int constant, not an int64, and therefore the shift will be done in int width. Correct would be sign |= ((TPQTGist) 1) (ptr-val % SIGLEN); The effect of this is at least that the high-order half of sign remains always zero. Depending on what the machine does with shifts exceeding the word width (which is undefined according to ANSI C), the bottom half might be messed up too. So we are failing to exploit the full intended sign space, which presumably is costing something in index efficiency. It looks to me like the values calculated by this routine end up on disk, and therefore we can't fix it without forcing an initdb, or at least REINDEX of all affected indexes. Is that correct? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly