Re: [PATCH] Simplify EXISTS subqueries containing LIMIT - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Simplify EXISTS subqueries containing LIMIT
Date
Msg-id 8669.1416701849@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Simplify EXISTS subqueries containing LIMIT  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> I'm reasonably happy with the patch now, the only small niggles are maybe
> the Assert() is probably not so much needed as transformLimitClause() seems
> to coerce to int8 anyway, and recompute_limits() does not bother with the
> Assert() when it does the same thing, either way, it's certainly doing no
> harm. The other thing was the regression tests, I'd rather see the tests
> use 2 separate tables for the EXISTS checks, but this is likely only
> because I'm thinking of doing some work in the future to remove duplicate
> joins from queries, so perhaps it's fine for now.

> Good work. Marking as ready for committer.

I've committed this patch with small adjustments; mostly, making the
comments more explicit.  But I also reordered the operations so that the
LIMIT-ectomy can be performed even if we decide the targetlist is unsafe.
This is within simplify_EXISTS_query's stated charter: it does not have
to be all-or-nothing.

(On reflection, we could zap a constant limit even when there are GROUP BY
etc, but it's probably not worth worrying about.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: postgres_fdw behaves oddly
Next
From: Amit Kapila
Date:
Subject: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]