| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Subplan result caching |
| Date: | 2018-05-25 14:28:12 |
| Message-ID: | CA+TgmoaDW2VC_S3vsVP0oaabZQMjOVRVH6XwJ0BZsQP=j3Hy9w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 23, 2018 at 6:03 AM, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Reiss | 2018-05-25 14:30:36 | Performance regression with PostgreSQL 11 and partitioning |
| Previous Message | Robert Haas | 2018-05-25 14:26:24 | Re: Subplan result caching |