| From: | Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel Seq Scan vs kernel read ahead |
| Date: | 2020-06-03 22:14:59 |
| Message-ID: | CAE-ML+90Rn4o_-3JA3ZoWgg8qCx=JU_875QppjA21i4KesAkYg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> It doesn't look like it's using table_block_parallelscan_nextpage() as
> a block allocator so it's not affected by the patch. It has its own
> thing zs_parallelscan_nextrange(), which does
> pg_atomic_fetch_add_u64(&pzscan->pzs_allocatedtids,
> ZS_PARALLEL_CHUNK_SIZE), and that macro is 0x100000.
My apologies, I was too hasty. Indeed, you are correct. Zedstore's
unit of work is chunks of the logical zstid space. There is a
correlation between the zstid and blocks: zstids near each other are
likely to lie in the same block or in neighboring blocks. It would be
interesting to try something like this patch for Zedstore.
Regards,
Soumyadeep
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Soumyadeep Chakraborty | 2020-06-03 22:18:31 | Re: Parallel Seq Scan vs kernel read ahead |
| Previous Message | Andres Freund | 2020-06-03 22:13:34 | Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 |