On Thu, 27 Oct 2022 at 15:50, Richard Guo wrote:
> I find the duplicate "Limit" node is not that concerning after I realize
> it may appear in other queries, such as
>
> explain (analyze, timing off, costs off)
> select * from (select * from (select * from generate_series(1,100)i limit 10)
> limi
On Wed, Oct 26, 2022 at 4:25 PM David Rowley wrote:
> One other thought I had about the duplicate "Limit" node in the final
> plan was that we could make the limit clause an Expr like
> LEAST(, 1). That way we could ensure we get at
> most 1 row, but perhaps less if the expression given in the L
On Fri, 14 Oct 2022 at 15:15, Richard Guo wrote:
> The v3 patch looks good to me.
Thank you for looking at that.
One other thought I had about the duplicate "Limit" node in the final
plan was that we could make the limit clause an Expr like
LEAST(, 1). That way we could ensure we get at
most 1
On Thu, Oct 13, 2022 at 6:43 PM David Rowley wrote:
> On Thu, 13 Oct 2022 at 21:17, Richard Guo wrote:
> >
> > On Thu, Oct 13, 2022 at 2:48 PM David Rowley
> wrote:
> >> To stop the planner from adding that final sort, I opted to hack the
> >> LimitPath's pathkeys to say that it's already sorte
On Thu, 13 Oct 2022 at 21:17, Richard Guo wrote:
>
> On Thu, Oct 13, 2022 at 2:48 PM David Rowley wrote:
>> To stop the planner from adding that final sort, I opted to hack the
>> LimitPath's pathkeys to say that it's already sorted by the
>> PlannerInfo's sort_pathkeys. That feels slightly icky
On Thu, Oct 13, 2022 at 2:48 PM David Rowley wrote:
> On Thu, 13 Oct 2022 at 16:47, Richard Guo wrote:
> > Currently in the patch the optimization is done before we check for
> > presorted paths or do the explicit sort of the cheapest path. How about
> > we move this optimization into the branch
On Thu, 13 Oct 2022 at 16:47, Richard Guo wrote:
> Currently in the patch the optimization is done before we check for
> presorted paths or do the explicit sort of the cheapest path. How about
> we move this optimization into the branch where we've found any
> presorted paths? Maybe something lik
On Thu, Oct 13, 2022 at 4:50 AM David Rowley wrote:
> The problem is that I'm only added the LimitPath to the
> cheapest_total_path. I think to make your case work we'd need to add
> the LimitPath only in cases where the distinct_pathkeys are empty but
> the sort_pathkeys are not and hasDistinct
On Thu, Oct 13, 2022 at 4:41 AM David Rowley wrote:
> We could do something like set some bool flag in PlannerInfo to tell
> the planner not to bother adding the final LimitPath as we've already
> added another which does the job, but is it really worth adding that
> complexity for this patch? Yo
On Thu, 13 Oct 2022 at 01:13, Richard Guo wrote:
> For DISTINCT ON, if all the distinct pathkeys are redundant but there
> are available sort pathkeys, then for adequately-presorted paths I think
> we can also apply this optimization, using a Limit 1 rather than Unique.
>
> regression=# explain (a
On Thu, 13 Oct 2022 at 00:30, Richard Guo wrote:
> I also have concerns about the 2 Limit nodes pointed by the comment
> inside the patch. Maybe we can check with limit_needed() and manually
> add the limit node only if there is no LIMIT clause in the origin query?
I wasn't hugely concerned about
On Wed, Oct 12, 2022 at 5:19 PM David Rowley wrote:
> When all the distinct pathkeys are redundant then there can only be,
> at most, 1 single distinct value. There may be many rows with that
> value, but we can remove those extra ones with a LIMIT 1 rather than
> troubling over needlessly uniqui
On Wed, Oct 12, 2022 at 5:19 PM David Rowley wrote:
> When all the distinct pathkeys are redundant then there can only be,
> at most, 1 single distinct value. There may be many rows with that
> value, but we can remove those extra ones with a LIMIT 1 rather than
> troubling over needlessly uniqui
13 matches
Mail list logo
