From: | Hartmut Holzgraefe <hartmut(dot)holzgraefe(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Having query cache in core |
Date: | 2018-05-11 13:21:08 |
Message-ID: | f8176968-432f-600b-784b-b27ddd085ac7@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11.05.2018 14:26, Tatsuo Ishii wrote:
> If any of the tables were
> modified, cache entries using the table must be removed.
> (these are already implemented in Pgpool-II's in memory query cache)
... and this is the expensive part in the MySQL implementation that
has rendered the query cache mostly useless for the last decade or so:
Unless you come up with a clever lockless implementation concurrent
writes on the same table effectively become serialized by this,
creating serious contention problems.
Peter Zaitsev once listed several points that could be improved to
make the query cache somewhat useful again, but in the end noone
really seemed to be interested in really doing so, including
Percona themselves, as apparently even without the contention issues
there are only few workloads these days that would significantly profit
from cached result sets.
https://www.percona.com/blog/2011/04/10/should-we-give-a-mysqlquery-cache-a-second-chance/
Maybe this list can be taken as a "what to avoid" hint sheet ...
--
hartmut
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2018-05-11 13:28:04 | Re: Considering signal handling in plpython again |
Previous Message | Sandeep Thakkar | 2018-05-11 13:18:12 | pg_locale compilation error with Visual Studio 2017 |