Re: Having query cache in core

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

In response to

Browse pgsql-hackers by date

  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