Re: Subplan result caching - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Subplan result caching
Date
Msg-id CA+TgmoaDW2VC_S3vsVP0oaabZQMjOVRVH6XwJ0BZsQP=j3Hy9w@mail.gmail.com
Whole thread Raw
In response to Re: Subplan result caching  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers
On Wed, May 23, 2018 at 6:03 AM, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> I think the cache should be limited in size, perhaps by work_mem.
> Also, there probably should be a GUC for this, defaulting to "off".

Eh, why?  Generally we want performance optimizations turned on by
default; otherwise only highly-knowledgeable users end up getting any
benefit.  An exception is when there's some significant downside to
the optimization, but I don't think I understand what the downside of
this could be.  Maybe it's bad if we populate the cache and never use
it?  But until the patch is written we don't know whether there's
really a case that regresses like that, and if there is, it would be
better to fix it so it doesn't rather than make the feature
off-by-default.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Subplan result caching
Next
From: Thomas Reiss
Date:
Subject: Performance regression with PostgreSQL 11 and partitioning