Re: Parallel Seq Scan vs kernel read ahead - Mailing list pgsql-hackers

From David Rowley
Subject Re: Parallel Seq Scan vs kernel read ahead
Date
Msg-id CAApHDvr36wssOYBQnst29nG1Xg-Ntf7qVPcj-mZh667X=2LTXg@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan vs kernel read ahead  (Soumyadeep Chakraborty <soumyadeep2007@gmail.com>)
List pgsql-hackers
Hi Soumyadeep,

Thanks for re-running the tests.

On Thu, 23 Jul 2020 at 06:01, Soumyadeep Chakraborty
<soumyadeep2007@gmail.com> wrote:
> On Tue, Jul 14, 2020 at 8:52 PM David Rowley <dgrowleyml@gmail.com> wrote:
> > It would be good to see EXPLAIN (ANALYZE, BUFFERS) with SET
> > track_io_timing = on; for each value of max_parallel_workers.
>
> As for running EXPLAIN ANALYZE, running that on this system incurs a
> non-trivial amount of overhead. The overhead is simply staggering.

I didn't really intend for that to be used to get an accurate overall
timing for the query. It was more to get an indication of the reads
are actually hitting the disk or not.

I mentioned to Kirk in [1] that his read speed might be a bit higher
than what his disk can actually cope with.  I'm not too sure on the
HDD he mentions, but if it's a single HDD then reading at an average
speed of 3457 MB/sec seems quite a bit too fast. It seems more likely,
in his cases, that those reads are mostly coming from the kernel's
cache.

David

[1] https://www.postgresql.org/message-id/CAApHDvoDzAzXEp+Ay2CfT3U=ZcD5NLD7K9_Y936bnHjzs5jkHw@mail.gmail.com



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Parallel worker hangs while handling errors.
Next
From: Ajin Cherian
Date:
Subject: Re: logical replication empty transactions