From: | Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com> |
---|---|
To: | Konrad Garus <konrad(dot)garus(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: shared_buffers advice |
Date: | 2010-05-27 18:22:10 |
Message-ID: | AANLkTikyiXIW0BuAqN5H8ylqUm73_Ev13IPIXfsa8aeO@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2010/5/27 Konrad Garus <konrad(dot)garus(at)gmail(dot)com>:
> 2010/5/27 Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>:
>
>> well, that is the projection of file in memory. only projection, but
>> the memory is still acquire. It is ok to rework this part and project
>> something like 128MB and loop. (in fact the code is needed for 9.0
>> because segment can be > 1GB, I didn't check what is the optimum
>> projection size yet)
>> So both yes at your questions :)
>
> So when I map 12 GB, this process will consume 1 GB and the time
> needed to browse through the whole 12 GB buffer?
Exactly. And the time to browse depend on the number of blocks already
in core memory.
I am interested by tests results and benchmarks if you are going to do some :)
>
> --
> Konrad Garus
>
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2010-05-27 18:28:36 | Re: Random Page Cost and Planner |
Previous Message | Tom Lane | 2010-05-27 16:41:28 | Re: Query causing explosion of temp space with join involving partitioning |