Alexander Korotkov <aekorot...@gmail.com> writes:
> On Sun, Nov 27, 2011 at 10:43 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 1. penalty is using both hard-wired penalty values (1.0, 2.0, etc) and
>> values obtained from subtype_diff. This is not good, because you have
>> no idea what scale the subtype differences will be expressed on. The
>> hard-wired values could be greatly larger than range widths, or greatly
>> smaller, resulting in randomly different index behavior.
> Current GiST code only compare penalty values of inserting same tuple. And
> don't see why it may alters. So, values obtained from subtype_diff
> and hard-wired values would be never compared each other.
I see your point that we only need the penalty values to be comparable
for the same "new" value, but I don't think that really answers my
objection, because you've had to lobotomize the logic. As an example,
if we have a new empty range to insert, and all the existing root-page
entries are ordinary finite ranges, this code will throw up its hands
and give them all the same 4.0 penalty value. Surely it would be better
to attempt to pick the smallest (narrowest) existing range. But to do
that, you have to pay attention to the subdiff value.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
