Re: [PATCH] Incremental sort (was: PoC: Partial sort) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Date
Msg-id 20190912154929.GA2254@alvherre.pgsql
Whole thread Raw
In response to Re: [PATCH] Incremental sort (was: PoC: Partial sort)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Re: [PATCH] Incremental sort (was: PoC: Partial sort)
List pgsql-hackers
On 2019-Jul-30, Tomas Vondra wrote:

> On Sun, Jul 21, 2019 at 01:34:22PM +0200, Tomas Vondra wrote:
> > 
> > I wonder if we're approaching this wrong. Maybe we should not reverse
> > engineer queries for the various places, but just start with a set of
> > queries that we want to optimize, and then identify which places in the
> > planner need to be modified.

[...]

> I've decided to do a couple of experiments, trying to make my mind about
> which modified places matter to diffrent queries. But instead of trying
> to reverse engineer the queries, I've taken a different approach - I've
> compiled a list of queries that I think are sensible and relevant, and
> then planned them with incremental sort enabled in different places.

[...]

> The list of queries (synthetic, but hopefully sufficiently realistic)
> and a couple of scripts to collect the plans is in this repository:
> 
>  https://github.com/tvondra/incremental-sort-tests-2
> 
> There's also a spreadsheet with a summary of results, with a visual
> representation of which GUCs affect which queries.

OK, so we have that now.  I suppose this spreadsheet now tells us which
places are useful and which aren't, at least for the queries that you've
tested.  Dowe that mean that we want to get the patch to consider adding
paths only the places that your spreadsheet says are useful?  I'm not
sure what the next steps are for this patch.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Re: Pulling up direct-correlated ANY_SUBLINK
Next
From: Tom Lane
Date:
Subject: Leakproofness of texteq()/textne()