From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
cc: James Coleman <jtc331@gmail.com>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Michael Paquier <michael@paquier.xyz>,
        Rafia Sabih <rafia.pghackers@gmail.com>, Peter Geoghegan <pg@bowt.ie>,
        Simon Riggs <simon@2ndquadrant.com>,
        Shaun Thomas <shaun.thomas@2ndquadrant.com>,
        Dmitry Dolgov <9erthalion6@gmail.com>,
        Alexander Korotkov <a.korotkov@postgrespro.ru>,
        PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>,
        Andreas Karlsson <andreas@proxel.se>
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
In-reply-to: <20200331215340.bbbrccbehmjb7dbx@development>
References: 
 <CAAaqYe_P9sJ4ACuaHRU-+pq0HAg76ei052BsUfuWjA9EwSkGMw@mail.gmail.com>
 <20200329031437.yvhogo25wdijwpqd@development>
 <CAAaqYe-rLqNBeCFq0Ruw4RUs5h1xbO2B1BGnjLq0k5Sw3a2gTg@mail.gmail.com>
 <CAAaqYe-M==BwbC47LeMM2HcUGHqCdynNMMyncrBa7t0AGzZGWQ@mail.gmail.com>
 <20200330014442.chqnwfmelm3ejsgr@development>
 <CAAaqYe__vp0QQHgUfiVe+NrcMpECfQgZO8iu2CEwVOcBgA+S0Q@mail.gmail.com>
 <20200330122426.wjdfpqiatv4ybui7@development>
 <CAAaqYe8hK3FpBRkAtTn1L_sETMUivoR=knoLf5by6Q7yLZnzTg@mail.gmail.com>
 <20200331011407.vwz3ektatgqyi6vy@development>
 <CAAaqYe8M-r4esHOg_46w3ojeUEB7KGZ4j2GAi6rLv0B9bHoiPg@mail.gmail.com>
 <20200331215340.bbbrccbehmjb7dbx@development>
Comments: In-reply-to Tomas Vondra <tomas.vondra@2ndquadrant.com>
	message dated "Tue, 31 Mar 2020 23:53:40 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2607.1585694132.1@sss.pgh.pa.us>
Date: Tue, 31 Mar 2020 18:35:32 -0400
Message-ID: <2608.1585694132@sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> In general, I think it'd be naive that we can make planner smarter with
> no extra overhead spent on planning, and we can never accept patches
> adding even tiny overhead. With that approach we'd probably end up with
> a trivial planner that generates just a single query plan, because
> that's going to be the fastest planner. A realistic approach needs to
> consider both the planning and execution phase, and benefits of this
> patch seem to be clear - if you have queries that do benefit from it.

I think that's kind of attacking a straw man, though.  The thing that
people push back on, or should push back on IMO, is when a proposed
patch adds significant slowdown to queries that it has no or very little
hope of improving.  The trick is to do expensive stuff only when
there's a good chance of getting a better plan out of it.

			regards, tom lane