| From: | Neil Conway <neilc(at)samurai(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)stack(dot)net> |
| Subject: | GiST: range of penalty method? |
| Date: | 2004-11-10 04:49:16 |
| Message-ID: | 1100062155.14777.29.camel@localhost.localdomain |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Does anyone know what the expected range of the "penalty" GiST method
is? (i.e. Is the legal range documented anywhere? Failing that, what
does existing GiST-based code expect?)
While rewriting gistchoose() in gist.c to be less obfuscated, it
occurred to me that (a) I don't think the existing code will work as
intended if a negative penalty is returned (b) it would be good to
define a "minimum legal penalty". Once the minimum penalty has been
returned for a particular location, GiST can know that all other
locations where it might insert the node will have a penalty greater
than or equal to that value, so gistchoose() can bail-out earlier.
Therefore, I'd like to make "0.0" is the minimum legal penalty, and
require all GiST "penalty" methods to return values >= 0. I think
requiring the penalty != NaN would also be a good idea. Comments?
Note that making this change to CVS tip results in a regression failure
in contrib/btree_gist. The regression.diffs are attached. The regression
tests for rtree_gist, tsearch, tsearch2 and pg_trgm succeed after making
the modification.
-Neil
| Attachment | Content-Type | Size |
|---|---|---|
| regression.diffs | text/x-patch | 994 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2004-11-10 05:08:29 | Re: [Pgsphere-dev] GIST index concurrency concern |
| Previous Message | John Hansen | 2004-11-10 04:42:04 | CREATE or REPLACE function pg_catalog.* |