On Wed, Jul 16, 2014 at 1:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
I've attached an updated patch which puts in some fast path code for
subquery type joins. I'm really not too sure on a good name for this
function. I've ended up with
David Rowley dgrowle...@gmail.com writes:
On Wed, Jul 16, 2014 at 1:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Notably, I felt that pathnode.c was a pretty questionable place to be
exporting distinctness-proof logic from, and after some reflection decided
to move those functions to
David Rowley dgrowle...@gmail.com writes:
I've attached an updated patch which puts in some fast path code for
subquery type joins. I'm really not too sure on a good name for this
function. I've ended up with query_supports_distinctness() which I'm not
that keen on, but I didn't manage to come
On Wed, Jul 9, 2014 at 12:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrow...@gmail.com writes:
On 9 July 2014 09:27, Tom Lane t...@sss.pgh.pa.us wrote:
On review it looks like analyzejoins.c would possibly benefit from an
earlier fast-path check as well.
Do you mean for
On Tue, Jul 8, 2014 at 4:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
On Mon, Jul 7, 2014 at 4:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I poked around to see if we didn't have some code already for that, and
soon found that not only do we have such
David Rowley dgrowle...@gmail.com writes:
On Tue, Jul 8, 2014 at 4:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a bit skeptical as to whether testing for that case is actually worth
any extra complexity. Do you have a compelling use-case? But anyway,
if we do want to allow it, why does it
On 9 July 2014 09:27, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
On Tue, Jul 8, 2014 at 4:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a bit skeptical as to whether testing for that case is actually
worth
any extra complexity. Do you have a compelling
David Rowley dgrow...@gmail.com writes:
On 9 July 2014 09:27, Tom Lane t...@sss.pgh.pa.us wrote:
On review it looks like analyzejoins.c would possibly benefit from an
earlier fast-path check as well.
Do you mean for non-subqueries? There already is a check to see if the
relation has no
On Mon, Jul 7, 2014 at 4:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrow...@gmail.com writes:
On 6 July 2014 03:20, Tom Lane t...@sss.pgh.pa.us wrote:
Just to note that I've started looking at this, and I've detected a
rather
significant omission: there's no check that the
David Rowley dgrowle...@gmail.com writes:
On Mon, Jul 7, 2014 at 4:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I poked around to see if we didn't have some code already for that, and
soon found that not only do we have such code (equality_ops_are_compatible)
but actually almost this entire patch
David Rowley dgrow...@gmail.com writes:
On 6 July 2014 03:20, Tom Lane t...@sss.pgh.pa.us wrote:
Just to note that I've started looking at this, and I've detected a rather
significant omission: there's no check that the join operator has anything
to do with the subquery's grouping operator.
David Rowley dgrowle...@gmail.com writes:
Attached is a delta patch between version 1.2 and 1.3, and also a
completely updated patch.
Just to note that I've started looking at this, and I've detected a rather
significant omission: there's no check that the join operator has anything
to do with
On 6 July 2014 03:20, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
Attached is a delta patch between version 1.2 and 1.3, and also a
completely updated patch.
Just to note that I've started looking at this, and I've detected a rather
significant omission:
On Sun, Jun 22, 2014 at 11:51 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 17 June 2014 11:04, David Rowley dgrowle...@gmail.com wrote:
On Wed, Jun 4, 2014 at 12:50 AM, Noah Misch n...@leadboat.com wrote:
As a point of procedure, I recommend separating the semijoin support
into
its
On Wed, Jun 25, 2014 at 10:03 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 23 June 2014 12:06, David Rowley dgrow...@gmail.com wrote:
It's not clear to me where you get the term sortclause from. This is
either the groupclause or distinctclause, but in the test cases you
provide this
On 26 June 2014 10:01, David Rowley dgrowle...@gmail.com wrote:
Did you comment on the transitive closure question? Should we add a
test for that, whether or not it works yet?
In my previous email.
I could change the the following to use c.id in the targetlist and group by
clause, but I'm
On 23 June 2014 12:06, David Rowley dgrow...@gmail.com wrote:
It's not clear to me where you get the term sortclause from. This is
either the groupclause or distinctclause, but in the test cases you
provide this shows this has nothing at all to do with sorting since
there is neither an order
Simon Riggs si...@2ndquadrant.com writes:
Other than that it looks pretty good to commit, so I'll wait a week
for other objections then commit.
I'd like to review this before it goes in. I've been waiting for it to
get marked ready for committer though.
regards, tom
On 24 June 2014 23:48, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Other than that it looks pretty good to commit, so I'll wait a week
for other objections then commit.
I'd like to review this before it goes in. I've been waiting for it to
get marked ready
On 17 June 2014 11:04, David Rowley dgrowle...@gmail.com wrote:
On Wed, Jun 4, 2014 at 12:50 AM, Noah Misch n...@leadboat.com wrote:
As a point of procedure, I recommend separating the semijoin support into
its
own patch. Your patch is already not small; delaying non-essential parts
will
On 22 June 2014 12:51, Simon Riggs si...@2ndquadrant.com wrote:
Looks good on initial look.
Tests 2 and 3 seem to test the same thing.
There are no tests which have multiple column clauselist/sortlists,
nor tests for cases where the clauselist is a superset of the
sortlist.
Test comments
On Wed, Jun 4, 2014 at 12:50 AM, Noah Misch n...@leadboat.com wrote:
As a point of procedure, I recommend separating the semijoin support into
its
own patch. Your patch is already not small; delaying non-essential parts
will
make the essential parts more accessible to reviewers.
In the
On Mon, Jun 2, 2014 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
TBH I think that trying to do anything at all for inner joins is probably
a bad idea. The cases where the optimization could succeed are so
On Fri, Jun 6, 2014 at 11:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Noah Misch n...@leadboat.com writes:
On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
A bit more crazy, but how about trying trying to plan joins with a added
one-time qual that checks the size of the
On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
On 2014-06-04 20:04:07 -0400, Noah Misch wrote:
On Wed, Jun 04, 2014 at 10:14:42AM -0400, Tom Lane wrote:
It's possible that we could apply the optimization only to queries that
have been issued directly by a client, but that
Noah Misch n...@leadboat.com writes:
On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
A bit more crazy, but how about trying trying to plan joins with a added
one-time qual that checks the size of the deferred trigger queue? Then
we wouldn't even need special case plans.
That,
On Thu, Jun 05, 2014 at 07:44:31PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
A bit more crazy, but how about trying trying to plan joins with a added
one-time qual that checks the size of the deferred trigger
On Wed, Jun 4, 2014 at 11:50 AM, Noah Misch n...@leadboat.com wrote:
On Wed, May 28, 2014 at 08:39:32PM +1200, David Rowley wrote:
The attached patch allows join removals for both sub queries with left
joins and also semi joins where a foreign key can prove the existence of
the record.
David Rowley dgrowle...@gmail.com writes:
On Wed, Jun 4, 2014 at 11:50 AM, Noah Misch n...@leadboat.com wrote:
When a snapshot can see modifications that queued referential integrity
triggers for some FK constraint, that constraint is not guaranteed to hold
within the snapshot until those
On Wed, Jun 04, 2014 at 10:14:42AM -0400, Tom Lane wrote:
David Rowley dgrowle...@gmail.com writes:
On Wed, Jun 4, 2014 at 11:50 AM, Noah Misch n...@leadboat.com wrote:
When a snapshot can see modifications that queued referential integrity
triggers for some FK constraint, that constraint
On 2014-06-04 20:04:07 -0400, Noah Misch wrote:
On Wed, Jun 04, 2014 at 10:14:42AM -0400, Tom Lane wrote:
It's possible that we could apply the optimization only to queries that
have been issued directly by a client, but that seems rather ugly and
surprise-filled.
... such as this idea.
On Wed, May 28, 2014 at 08:39:32PM +1200, David Rowley wrote:
The attached patch allows join removals for both sub queries with left
joins and also semi joins where a foreign key can prove the existence of
the record.
When a snapshot can see modifications that queued referential integrity
David Rowley dgrowle...@gmail.com writes:
I'm not quite there with inner joins yet. I'm still getting my head around
just where the join quals are actually stored.
TBH I think that trying to do anything at all for inner joins is probably
a bad idea. The cases where the optimization could
* Tom Lane (t...@sss.pgh.pa.us) wrote:
David Rowley dgrowle...@gmail.com writes:
I'm not quite there with inner joins yet. I'm still getting my head around
just where the join quals are actually stored.
TBH I think that trying to do anything at all for inner joins is probably
a bad idea.
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
TBH I think that trying to do anything at all for inner joins is probably
a bad idea. The cases where the optimization could succeed are so narrow
that it's unlikely to be worth adding cycles to every query to
On Sun, May 25, 2014 at 5:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
I agree that there are not many cases left to remove the join that remain
after is_simple_subquery() has decided not to pullup the subquery. Some
of
the perhaps more common cases
David Rowley dgrowle...@gmail.com writes:
I agree that there are not many cases left to remove the join that remain
after is_simple_subquery() has decided not to pullup the subquery. Some of
the perhaps more common cases would be having windowing functions in the
subquery as this is what you
On Mon, May 19, 2014 at 5:47 PM, Dilip kumar dilip.ku...@huawei.com wrote:
So I think now when you are considering this join removal for subqueries
then this can consider other case also like unique index inside subquery,
because in attached patch unique index is considered only if its
On 23 May 2014 12:43 David Rowley Wrote,
I'm hitting a bit of a roadblock on point 1. Here's a snipped from my latest
attempt:
if (bms_membership(innerrel-relids) == BMS_SINGLETON)
{
int subqueryrelid =
On Fri, May 23, 2014 at 8:28 PM, Dilip kumar dilip.ku...@huawei.com wrote:
On 23 May 2014 12:43 David Rowley Wrote,
I'm hitting a bit of a roadblock on point 1. Here's a snipped from my
latest attempt:
if (bms_membership(innerrel-relids) ==
BMS_SINGLETON)
David Rowley dgrowle...@gmail.com writes:
I've just had a bit of a look at implementing checks allowing subqueries
with unique indexes on the join cols being removed,
I'm a bit confused by this statement of the problem. I thought the idea
was to recognize that subqueries with DISTINCT or GROUP
On Sat, May 24, 2014 at 3:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
I've just had a bit of a look at implementing checks allowing subqueries
with unique indexes on the join cols being removed,
I'm a bit confused by this statement of the problem. I
On Tue, May 20, 2014 at 11:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
I'm also now wondering if I need to do some extra tests in the existing
code to ensure that the subquery would have had no side affects.
You should probably at least refuse the
On Mon, May 19, 2014 at 9:22 PM, Dilip kumar dilip.ku...@huawei.com wrote:
On 19 May 2014 12:15 David Rowley Wrote,
May be we can convert my above example like below à in this case we
have unique index on field a and we are limiting it by first 100 tuple
(record are already order
David Rowley dgrowle...@gmail.com writes:
I'm also now wondering if I need to do some extra tests in the existing
code to ensure that the subquery would have had no side affects.
You should probably at least refuse the optimization if the subquery's
tlist contains volatile functions.
Functions
On Mon, May 19, 2014 at 5:47 PM, Dilip kumar dilip.ku...@huawei.com wrote:
On 18 May 2014 16:38 David Rowley Wrote
Sound like a good idea to me..
I have one doubt regarding the implementation, consider the below query
Create table t1 (a int, b int);
Create table t2 (a int, b int);
On 19 May 2014 12:15 David Rowley Wrote,
I think you are right here, it would be correct to remove that join, but I
also think that the query in question could be quite easily be written as:
select t1.a from t1 left join t2 on t1.a=t2.b;
Where the join WILL be removed. The distinct clause here
On Sat, May 17, 2014 at 8:57 PM, David Rowley dgrowle...@gmail.com wrote:
I'm currently in the early stages of looking into expanding join removals.
Currently left outer joins can be removed if none of the columns of the
table are required for anything and the table being joined is a base
On 18 May 2014 16:38 David Rowley Wrote
Sound like a good idea to me..
I have one doubt regarding the implementation, consider the below query
Create table t1 (a int, b int);
Create table t2 (a int, b int);
Create unique index on t2(b);
select x.a from t1 x left join (select distinct t2.a a1,
On Sat, May 17, 2014 at 8:57 PM, David Rowley dgrowle...@gmail.com wrote:
I'm currently in the early stages of looking into expanding join removals.
As I said above, I'm in the early stages of looking at this and I'm
currently a bit confused. Basically I've put a breakpoint at the top of
the
David Rowley dgrowle...@gmail.com writes:
It looks like the existing join removals are done quite early in the
planning and redundant joins are removed before any subqueries from that
query are planned. So this innerrel-subroot-parse has not been done yet.
It seems to be done later in
On Sun, May 18, 2014 at 2:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
It looks like the existing join removals are done quite early in the
planning and redundant joins are removed before any subqueries from that
query are planned. So this
52 matches
Mail list logo
