Re: [PATCH] Incremental sort (was: PoC: Partial sort)
От | Tomas Vondra |
---|---|
Тема | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
Дата | |
Msg-id | 20200331225357.o4o55wjldlbx4kdt@development обсуждение исходный текст |
Ответ на | Re: [PATCH] Incremental sort (was: PoC: Partial sort) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] Incremental sort (was: PoC: Partial sort)
|
Список | pgsql-hackers |
On Tue, Mar 31, 2020 at 06:35:32PM -0400, Tom Lane wrote: >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. > Yeah, I agree with that. I think the main issue is that we don't really know what the "expensive stuff" is in this case, so it's not really clear how to be smarter :-( One possibility is that it's just one of those regressions due to change in binary layout, but I'm not sure know how to verify that. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: