Re: SLRUs in the main buffer pool - Page Header definitions

Hi,

> Agreed that we'd certainly want to make sure it's all correct and to do
> performance testing but in terms of how many buffers... isn't much of
> the point of this that we have data in memory because it's being used
> and if it's not then we evict it? That is, I wouldn't think we'd have
> set parts of the buffer pool for SLRUs vs. regular data but would let
> the actual demand drive what pages are in the cache and I thought that
> was part of this proposal and part of the reasoning behind making this
> change.
>
> There's certainly an argument to be made that our current cache
> management strategy doesn't account very well for the value of pages
> (eg: btree root pages vs. random heap pages, perhaps) and that'd
> certainly be a good thing to improve on, but that's independent of this.
> If it's not, then that's certainly moving the goal posts a very long way
> in terms of this effort.

During the triage of the patches submitted for the September CF [1] I
noticed that the corresponding CF entry [2] has two threads linked.
Only the first thread was used by CF bot [3], also Heikki and Thomas
were listed as the authors. The patch from the first thread rotted and
was not updated for some time which resulted in marking the patch as
RwF for now [4]

It looks like the patch in *this* thread was never registered on the
commitfest and/or tested by CF bot, unless I'm missing something.
Unfortunately it's a bit late to register it for the September CF
especially considering the fact that it doesn't apply at the moment.

This being said, please consider submitting the patch for the upcoming
CF. Also, please consider joining the efforts and having one thread
with a single patchset rather than different threads with different
competing patches. This will simplify the work of the reviewers a lot.

Personally I would suggest taking one step back and agree on a
particular RFC first and then continue working on a single patchset
according to this RFC. We did it in the past in similar cases and this
approach proved to be productive.

[1]: https://postgr.es/m/0737f444-59bb-ac1d-2753-873c40da0840%40eisentraut.org
[2]: https://commitfest.postgresql.org/44/3514/
[3]: http://cfbot.cputube.org/
[4]: https://postgr.es/m/CAJ7c6TN%3D1EF1bTA6w8W%3D0e_Bj%2B-jsiHK0ap1uC_ZUGjwu%2B4JGw%40mail.gmail.com

--
Best regards,
Aleksander Alekseev