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
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? |