From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgsql: Apply a band-aid fix for the problem that 8.2 and up completely |
Date: | 2007-09-01 00:32:10 |
Message-ID: | 5028.1188606730@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)postgresql(dot)org> writes:
>> Log Message:
>> -----------
>> Apply a band-aid fix for the problem that 8.2 and up completely misestimate
>> the number of rows likely to be produced by a query such as
>> SELECT * FROM t1 LEFT JOIN t2 USING (key) WHERE t2.key IS NULL;
> I'm a little wary of backpatching planner logic changes like this and another
> instance in the past.
I probably wouldn't have even made this patch if 8.2's behavior weren't
so completely broken on an important class of query. For a significant
number of people, this is a bug fix.
In any case, there have been planner changes much larger than this
committed into the 8.2 branch since release --- both the outer join
rearrangement logic and choose_bitmap_and have needed significant
surgery.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | User H-saito | 2007-09-01 00:53:55 | psqlodbc - psqlodbc: Some changes. |
Previous Message | Gregory Stark | 2007-09-01 00:23:59 | Re: pgsql: Apply a band-aid fix for the problem that 8.2 and up completely |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-01 00:46:01 | Re: [PATCH] Lazy xid assingment V2 |
Previous Message | Gregory Stark | 2007-09-01 00:23:59 | Re: pgsql: Apply a band-aid fix for the problem that 8.2 and up completely |