From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Eric Ridge <e_ridge(at)tcdi(dot)com> |
Subject: | Re: planner missing a trick for foreign tables w/OR conditions |
Date: | 2013-12-17 19:20:18 |
Message-ID: | 14601.1387308018@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Dec 17, 2013 at 12:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> (I wonder if it'd be worth inserting a check that
>> there's not already a manually-generated equivalent clause, too ...)
> Sounds a little too clever IMHO.
The argument for doing it is that we might otherwise find ourselves
degrading the plans for previously-manually-optimized queries. On the
other hand, the existing index-driven code has probably forestalled the
need for many people to do that; at least, I don't recall seeing much
discussion of doing that sort of thing by hand.
I'm happy to leave the issue out of the first version of the patch,
anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-12-17 19:26:36 | Re: planner missing a trick for foreign tables w/OR conditions |
Previous Message | Adrian Klaver | 2013-12-17 19:01:22 | Re: SSL: better default ciphersuite |