Tomas Vondra <t...@fuzzy.cz> writes:
> I can't reproduce any of the issues anymore - I've tested both 9.2 and
> 9.3 branches (both containing the already commited fixes). And not only
> that the issues seem to be gone, but I'm actually getting significantly
> better performance.
Cool. I noticed that it seemed faster too, but hadn't tried to quantify
that.
> I've also tested both branches (9.2 and 9.3) with the provided patch,
> and I can't reproduce any of the errors, but the performance seems to be
> equal to the old code. So it seems that the performance boost is due to
> the changes to the penalty function. Nice!
Yeah, the old penalty function was pretty badly broken with any non-C
sort order.
>> your report that the behavior is unstable, because I get the same result
>> each time if I start from an empty (truncated) table, with or without
>> the patch. You may be seeing some further bug(s). Could you test this
>> fix against your own test cases?
> This is what I meant by unstability:
> ....
> Notice the numbers change all the time.
[ scratches head... ] In HEAD, that's not so surprising because of
commit ba1cc6501, which added some randomness to choices about which
GiST page to insert new entries to (which could then affect whether the
union-calculation bugs got exercised). If you saw that in older
branches, though, it might merit some further investigation.
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
