On 2018-03-01 14:49:26 -0500, Robert Haas wrote:
> On Thu, Mar 1, 2018 at 2:29 PM, Andres Freund <andres@anarazel.de> wrote:
> > Right. Which might be very painful latency wise. And with poolers it's
> > pretty easy to get into situations like that, without the app
> > influencing it.
>
> Really? I'm not sure I believe that. You're talking perhaps a few
> milliseconds - maybe less - of additional latency on a connection
> that's been idle for many minutes.
I've seen latency increases in second+ ranges due to empty cat/sys/rel
caches. And the connection doesn't have to be idle, it might just have
been active for a different application doing different things, thus
accessing different cache entries. With a pooler you can trivially end
up switch connections occasionally between different [parts of]
applications, and you don't want performance to suck after each time.
You also don't want to use up all memory, I entirely agree on that.
> Anyway, I don't mind making the exact timeout a GUC (with 0 disabling
> the feature altogether) if that addresses your concern, but in general
> I think that it's reasonable to accept that a connection that's been
> idle for a long time may have a little bit more latency than usual
> when you start using it again.
I don't think that'd quite address my concern. I just don't think that
the granularity (drop all entries older than xxx sec at the next resize)
is right. For one I don't want to drop stuff if the cache size isn't a
problem for the current memory budget. For another, I'm not convinced
that dropping entries from the current "generation" at resize won't end
up throwing away too much.
If we'd a guc 'syscache_memory_target' and we'd only start pruning if
above it, I'd be much happier.
Greetings,
Andres Freund
