Re: FETCH FIRST clause PERCENT option
От | Tomas Vondra |
---|---|
Тема | Re: FETCH FIRST clause PERCENT option |
Дата | |
Msg-id | 20190405151145.qcxcwxg2bqihzph4@development обсуждение исходный текст |
Ответ на | Re: FETCH FIRST clause PERCENT option (Surafel Temesgen <surafel3000@gmail.com>) |
Список | pgsql-hackers |
On Fri, Apr 05, 2019 at 03:14:56PM +0300, Surafel Temesgen wrote: >On Tue, Mar 26, 2019 at 5:46 PM Tomas Vondra <tomas.vondra@2ndquadrant.com> >wrote: > >> On Tue, Mar 26, 2019 at 03:06:52PM +0300, Surafel Temesgen wrote: >> >On Thu, Feb 28, 2019 at 11:16 PM Tomas Vondra < >> tomas.vondra@2ndquadrant.com> >> >wrote: >> > >> >> >> >> To give you a (admittedly, somewhat contrived and artificial example): >> >> >> >> SELECT * FROM t1 WHERE id IN ( >> >> SELECT id FROM t2 ORDER BY x FETCH FIRST 10 PERCENT ROWS ONLY >> >> ); >> >> >> >> Maybe this example is bogus and/or does not really matter in practice. I >> >> don't know, but I've been unable to convince myself that's the case. >> > >> > >> >does this means we abandon incremental approach? and am not sure of >> >calculating >> >percentage after OFFSET clause is acceptable or not >> > >> >> I don't follow. I don't think I've suggested to abandon the incremental >> approach - I've explained why I think it's what the patch should be doing, >> and illustrated that with an example. >> > >but it is more complex than the previous approach and it will be more >complex >in starting calculating percentage before offset row count. Doesn't >simplicity prefer? > Sure, simplicity has it's value. And often the simplest solution is the best one. But in But in plenty of cases it's a tradeoff between simplicity and efficiency, i.e. the simplest solution may perform poorly. I've tried to explain why I think the incremental solution is the right approach here - not having to always execute the subplan to completion. I still haven't heard reasons why that argument is irrelevant (it may be). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: