Robert Haas writes:
> On Tue, Dec 17, 2013 at 12:28 PM, Tom Lane wrote:
>> So at this point I'm pretty much talked into it. We could eliminate the
>> dependence on indexes entirely, and replace this code with a step that
>> simply tries to pull single-base-relation quals out of ORs wherever it c
Simon Riggs writes:
> What surprises me is we don't have an API that allows an FDW to decide
> what it can accept or not. It seems strange to have a unilateral
> decision by our planner about what another planner is capable of.
Uh, what?
There's certainly missing features in our FDW APIs --- no
Robert Haas writes:
> On Tue, Dec 17, 2013 at 12:28 PM, Tom Lane 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 ourse
On 17 December 2013 17:28, Tom Lane wrote:
> So at this point I'm pretty much talked into it. We could eliminate the
> dependence on indexes entirely, and replace this code with a step that
> simply tries to pull single-base-relation quals out of ORs wherever it can
> find one. You could argue
On Tue, Dec 17, 2013 at 12:28 PM, Tom Lane wrote:
> I had been thinking it would fall down if there are several OR conditions
> affecting different collections of rels, but after going through the math
> again, I'm now thinking I was wrong and it does in fact work out. As you
> say, we do depend
Robert Haas writes:
> On Mon, Dec 16, 2013 at 6:59 PM, Tom Lane wrote:
>> The hard part is not extracting the partial qual. The hard part is
>> trying to make sure that adding this entirely-redundant scan qual doesn't
>> catastrophically degrade join size estimates.
> OK, I had a feeling that's
On Mon, Dec 16, 2013 at 6:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Dec 16, 2013 at 2:04 PM, Tom Lane wrote:
>>> The problem is that that optimization is a crock; see the comments
>>> for create_or_index_quals(). We can't just turn it loose to CNF-ify
>>> every OR it might find.
Robert Haas writes:
> On Mon, Dec 16, 2013 at 2:04 PM, Tom Lane wrote:
>> The problem is that that optimization is a crock; see the comments
>> for create_or_index_quals(). We can't just turn it loose to CNF-ify
>> every OR it might find. The case that we support at the moment is
>> to CNF-ify
On Mon, Dec 16, 2013 at 2:04 PM, Tom Lane wrote:
> The problem is that that optimization is a crock; see the comments
> for create_or_index_quals(). We can't just turn it loose to CNF-ify
> every OR it might find. The case that we support at the moment is
> to CNF-ify whichever single OR conditi
Robert Haas writes:
> Consider a query such as:
> SELECT * FROM a, b WHERE (a.x = 42 AND b.y = 43) OR (a.x = 44 AND b.z = 45);
> If a and/or b are regular tables, the query planner will cleverly
> consider the possibility of using an index on a to filter for rows
> with a.x = 42 OR a.x = 44, or o
On Mon, Dec 16, 2013 at 12:41:43PM -0500, Robert Haas wrote:
> Consider a query such as:
>
> SELECT * FROM a, b WHERE (a.x = 42 AND b.y = 43) OR (a.x = 44 AND b.z = 45);
>
> If a and/or b are regular tables, the query planner will cleverly
> consider the possibility of using an index on a to filt
Consider a query such as:
SELECT * FROM a, b WHERE (a.x = 42 AND b.y = 43) OR (a.x = 44 AND b.z = 45);
If a and/or b are regular tables, the query planner will cleverly
consider the possibility of using an index on a to filter for rows
with a.x = 42 OR a.x = 44, or of using an index on b to filte
12 matches
Mail list logo
