From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: issues with range types, btree_gist and constraints |
Date: | 2013-02-08 04:07:00 |
Message-ID: | 27342.1360296420@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tomas Vondra <tv(at)fuzzy(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-02-08 04:38:18 | Re: Vacuum/visibility is busted |
Previous Message | Tom Lane | 2013-02-08 03:55:38 | Re: performance bug in instrument.c |