| From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Tuning threshold for BAS_BULKREAD (large tables) |
| Date: | 2019-01-22 08:36:28 |
| Message-ID: | 4154037a-50e1-7fbf-9521-3589ec975f42@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 1/22/19 1:35 AM, Jamison, Kirk wrote:
>
> Hi,
>
> I have a source code-related question on BufferAccessStrategyType
> BAS_BULKREAD.
>
> Currently, this access method is set internally to cache tables larger
> than 1/4 of shared_buffers.
>
> src/backend/access/heap/heapam.c:initscan()
>
> if (!RelationUsesLocalBuffers(scan->rs_rd) &&
>
> scan->rs_nblocks > NBuffers / 4)
>
> ...
>
> /* During a rescan, keep the previous strategy object. */
>
> if (scan->rs_strategy == NULL)
>
> scan->rs_strategy = GetAccessStrategy(BAS_BULKREAD);
>
> Users can tune their shared_buffers size, but not able to tune this component.
>
> I'm just wondering how it affects the current workload when the table size
> is larger than the database.
>
How can a subset of the database be larger than the database?
--
Angular momentum makes the world go 'round.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jamison, Kirk | 2019-01-22 09:00:17 | RE: Tuning threshold for BAS_BULKREAD (large tables) |
| Previous Message | Fabio Pardi | 2019-01-22 08:11:15 | Re: Memory and hard ware calculation : |