| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel Seq Scan vs kernel read ahead |
| Date: | 2020-05-24 18:17:34 |
| Message-ID: | CAApHDvqk43QPahyUcgOV8xAYMJH+TXy5PLm1PLk9Ow7D0Q929g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 23 May 2020 at 06:31, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, May 21, 2020 at 6:28 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > Right, I think it's safe. I think you were probably right that
> > ramp-up isn't actually useful though, it's only the end of the scan
> > that requires special treatment so we don't get unfair allocation as
> > the work runs out, due to course grain.
>
> The ramp-up seems like it might be useful if the query involves a LIMIT.
That's true, but I think the intelligence there would need to go
beyond, "if there's a LIMIT clause, do ramp-up", as we might have
already fully ramped up well before the LIMIT is reached.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Victor Yegorov | 2020-05-24 18:30:15 | Failure to create GiST on ltree column |
| Previous Message | Ranier Vilela | 2020-05-24 17:50:08 | Re: PostgresSQL 13.0 Beta 1 on Phoronix |