From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)postgresql(dot)org> |
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:23:59 |
Message-ID: | 87hcmf44io.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
"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.
Even if the new logic is better in 99% of cases people with existing systems
will have already dealt with the 99% of cases where the existing releases come
up with poor plans. It seems the only people this patch will affect are the 1%
for whom the old planner works fine and upgrading breaks their application.
I'm not sure I would advocate rolling this particular commit back though,
especially since there's already at least one other planner change iirc.
Perhaps just noting the planner changes specifically in the release
announcement as possible compatibility gotchas is what's needed.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-01 00:32:10 | Re: pgsql: Apply a band-aid fix for the problem that 8.2 and up completely |
Previous Message | User Hinoue | 2007-08-31 23:40:10 | psqlodbc - psqlodbc: The version is now 8.2.0403. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-01 00:32:10 | Re: pgsql: Apply a band-aid fix for the problem that 8.2 and up completely |
Previous Message | Gregory Stark | 2007-08-31 23:55:47 | Re: [PATCH] Lazy xid assingment V2 |