Re: FETCH FIRST clause PERCENT option - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: FETCH FIRST clause PERCENT option
Date
Msg-id 20190405151145.qcxcwxg2bqihzph4@development
Whole thread Raw
In response to Re: FETCH FIRST clause PERCENT option  (Surafel Temesgen <surafel3000@gmail.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Failure in contrib test _int on loach
Next
From: Antonin Houska
Date:
Subject: Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3