Robert Haas <robertmhaas@xxxxxxxxx> writes: > Let's back up a moment and talk about what the overall goal is, here. > Ideally, we would like PostgreSQL to have excellent performance at all > times, under all circumstances, with minimal tuning. Therefore, we do > NOT want to add variables that will, by design, need constant manual > adjustment. That is why I suggested that Tom's idea of an > assume_cached GUC is probably not what we really want to do. On the > other hand, what I understand Mladen to be suggesting is something > completely different. He's basically saying that, of course, he wants > it to work out of the box most of the time, but since there are > guaranteed to be cases where it doesn't, how about providing some > knobs that aren't intended to be routinely twaddled but which are > available in case of emergency? Bravo, I say! Um ... those are exactly the same thing. You're just making different assumptions about how often you will need to twiddle the setting. Neither assumption is based on any visible evidence, unfortunately. I was thinking of assume_cached as something that could be set-and-forget most of the time, and you're entirely right to criticize it on the grounds that maybe it wouldn't. But to support a proposal that doesn't even exist yet on the grounds that it *would* be set-and-forget seems a tad inconsistent. We can't make that judgment without a whole lot more details than have been provided yet for any idea in this thread. I do think that something based around a settable-per-table caching percentage might be a reasonable way to proceed. But the devil is in the details, and we don't have those yet. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
