Ühel kenal päeval, E, 2007-03-05 kell 04:15, kirjutas Tom Lane:
> "Luke Lonergan" <LLonergan@greenplum.com> writes:
> > I think you're missing my/our point:
>
> > The Postgres shared buffer cache algorithm appears to have a bug. When
> > there is a sequential scan the blocks are filling the entire shared
> > buffer cache. This should be "fixed".
>
> No, this is not a bug; it is operating as designed.
Maybe he means that there is an oversight (aka "bug") in the design ;)
> The point of the
> current bufmgr algorithm is to replace the page least recently used,
> and that's what it's doing.
>
> If you want to lobby for changing the algorithm, then you need to
> explain why one test case on one platform justifies de-optimizing
> for a lot of other cases.
If you know beforehand that you will definitely overflow cache and not
reuse it anytime soon, then it seems quite reasonable to not even start
polluting the cache. Especially, if you get a noticable boost in
performance while doing so.
> In almost any concurrent-access situation
> I think that what you are suggesting would be a dead loss
Only if the concurrent access patern is over data mostly fitting in
buffer cache. If we can avoid polluting buffer cache with data we know
we will use only once, more useful data will be available.
> --- for
> instance we might as well forget about Jeff Davis' synchronized-scan
> work.
Depends on ratio of system cache/shared buffer cache. I don't think
Jeff's patch is anywere near the point it needs to start worrying about
data swapping between system cache and shared burrers, or L2 cache usage
> In any case, I'm still not convinced that you've identified the problem
> correctly, because your explanation makes no sense to me. How can the
> processor's L2 cache improve access to data that it hasn't got yet?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
