Re: LRU and full table scans

"Mike Mascari" <mascarm(at)mascari(dot)com> escribi en el mensaje
news:3C7C9449(dot)B747532B(at)mascari(dot)com(dot)(dot)(dot)
> On general a discussion has been taking place regarding cached query
> plans and how MySQL invented them. Of course, this is totally false. I
> remembered a nice paragraph in the Oracle docs as to the process by
> which Oracle uses shared SQL areas to share the execution plan of
> identical statements, flushing the area whenever a dependent object was
> modified. In searching for the reference, however, I stumbled an
> interesting fact. Unlike normal queries where blocks are added to the
> MRU end of an LRU list, full table scans add the blocks to the LRU end
> of the LRU list. I was wondering, in the light of the discussion of
> using LRU-K, if PostgreSQL does, or if anyone has tried, this technique?
>
> Mike Mascari
> mascarm(at)mascari(dot)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

First Hello, Second...Yes, I'm doing some studies on the buffer manager and
also studying and implementing different policys, one of them is the LRU-K.

By the time I don't have any results, I'm just preparing to run the TPC-H
benchmark to test all the policys that I have implemented.
I have implemented some policys for the buffer manager, some better and some
worst than LRU (FIFO, LFU, LRD, FBR, LRU-K, LRFU, 4 CLOCK policys (or second
chance), CORRELATED REFERENCES, and different combinations of them like
(LFU+CLOCK+AGING(by division or by substraction)+CORRELATED REFERENCES)),
there are seven principal policys and seven "add-on's" that could be applyed
to them, resulting in 25 combinations of policys.