From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | 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-21 21:59:58 |
Message-ID: | CAApHDvp8DYsi+oD1R_WVjhqZRVSRufsUwgSKVyD1HhHHfj5kAQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 21 May 2020 at 17:06, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> For the patch. I know you just put it together quickly, but I don't
> think you can do that ramp up the way you have. It looks like there's
> a risk of torn reads and torn writes and I'm unsure how much that
> could affect the test results here.
Oops. On closer inspection, I see that memory is per worker, not
global to the scan.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2020-05-21 22:27:15 | Re: Parallel Seq Scan vs kernel read ahead |
Previous Message | Tomas Vondra | 2020-05-21 21:41:22 | Re: Trouble with hashagg spill I/O pattern and costing |