Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 17, 2013 at 12:28 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 16, 2013 at 6:59 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Dec 17, 2013 at 12:28 PM, Tom Lane t...@sss.pgh.pa.us 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
On 17 December 2013 17:28, Tom Lane t...@sss.pgh.pa.us 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.
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 17, 2013 at 12:28 PM, Tom Lane t...@sss.pgh.pa.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
Simon Riggs si...@2ndquadrant.com 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
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 filter
Robert Haas robertmh...@gmail.com 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
On Mon, Dec 16, 2013 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 16, 2013 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Dec 16, 2013 at 6:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 16, 2013 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The problem is that that optimization is a crock; see the comments
for create_or_index_quals(). We can't just turn
11 matches
Mail list logo
