Re: FETCH FIRST clause PERCENT option

From: Surafel Temesgen <surafel3000(at)gmail(dot)com>
To: Ryan Lambert <ryan(at)rustprooflabs(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, Mark Dilger <hornschnorter(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Subject: Re: FETCH FIRST clause PERCENT option
Date: 2019-07-17 09:45:17
Message-ID: CALAY4q-crgcaUhn+CMnXxqcP7yw15bws2DSzRT2+wdc6J-33ww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Ryan,
On Tue, Jul 9, 2019 at 4:13 PM Ryan Lambert <ryan(at)rustprooflabs(dot)com> wrote:

>
> "It is possible for FETCH FIRST N PERCENT to create poorly performing
> query plans when the N supplied exceeds 50 percent. In these cases query
> execution can take an order of magnitude longer to execute than simply
> returning the full table. If performance is critical using an explicit row
> count for limiting is recommended."
>

I don’t understand how fetch first n percent functionality can be replaced
with explicit row count limiting. There may be a way to do it in a client
side but we can not be sure of its performance advantage

regards

Surafel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tushar 2019-07-17 09:55:43 pg_rewind is failing on PG v12 BETA/PG HEAD
Previous Message Amit Langote 2019-07-17 09:08:48 Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?