Hacker News Reader

Comment by wruza | Hacker News Reader

I think it is a combination of factors, but notably it is 1) 426GB table on 7200rpm hdd, 2) SeqScan of 8 rows which is not computationally expensive. It basically goes through a very big file on hdd, probably for the purpose of presentation, not to show some impressive per-core efficiency.

View on HN

Agreed: Table: 426GB, RAM: 256GB, and then he says "and it is clear that having more than 10 workers will not give any significant performance boost". Quite expected if it's IO bottlnecked. It doesn't sound like it's about presentation. Maybe I'm missing something.

IO bottlenecking shouldn't prevent parallelism helping.

One theoretical solution is to have millions of parallel queries, and rather than doing random reads to satisfy them, just read the whole table sequentially.

Query latency is high, but throughout is then unconstrained.

> and rather than doing random reads to satisfy them, just read the whole table sequentially

OK, good point, I believe this is called a carousel read (spent 5 mins looking for a link, sorry no luck. I know MSSQL does a slightly fancier version of it).

I think the original article was unclear in what it was trying for, actual performance or exposition.

Edit: could have utterly sworn it was a carousel read, but no cigar. Here it is https://www.mssqltips.com/sqlservertip/4472/sql-server-enter...

Postgres does this, too; at least to some degree. They call it "synchronized sequential scans".

Reply on news.ycombinator.com