Re: Parallel Seq Scan vs kernel read ahead
| От | Soumyadeep Chakraborty |
|---|---|
| Тема | Re: Parallel Seq Scan vs kernel read ahead |
| Дата | |
| Msg-id | CAE-ML+90Rn4o_-3JA3ZoWgg8qCx=JU_875QppjA21i4KesAkYg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Parallel Seq Scan vs kernel read ahead (David Rowley <dgrowleyml@gmail.com>) |
| Ответы |
Re: Parallel Seq Scan vs kernel read ahead
|
| Список | 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
В списке pgsql-hackers по дате отправления: