From: | satoshi(dot)nagayasu(at)gmail(dot)com |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | craig(at)postnewspapers(dot)com(dot)au, adarsh(dot)sharma(at)orkash(dot)com, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Memcached for Database server |
Date: | 2011-05-18 06:20:12 |
Message-ID: | BANLkTi=KAcBfWFyj3Rw=rr1JmP0hg8LRLQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
2011/5/18 Tatsuo Ishii <ishii(at)postgresql(dot)org>:
>> How do you handle statements that rely on current_timestamp, random(),
>> etc? What about if their reliance is via a function? Is that just an
>> understood limitation of the cache, that it'll cache even queries that
>> don't really make sense to cache?
>
> Probably we should cache the result of a query which containts no
> functions or a query which only contains immutable functions.
From my point of view, that's the trade off things.
I think database doesn't need to handle all situations and conditions.
In other words, "One size does not fit all."
Honestly, I'm not interested in building a complex and huge tool.
I love "Keep it simple, stupid" discipline. So, I just created a tiny tool,
which would be useful in many situations, not *all* situations.
In pqc, a programmer is still able to handle life cycle of the cache
with using hints. I think it's enough to solve many performance issues.
That's what I wanted to pqc.
Of course, if rich customers want me to invest *more integrated*
query cache for PostgreSQL, I will welcome them. :)
Regards,
--
NAGAYASU Satoshi <satoshi(dot)nagayasu(at)gmail(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | G. P. | 2011-05-18 07:28:51 | Re: re-install postgres/postGIS without Loosing data?? |
Previous Message | Tatsuo Ishii | 2011-05-18 05:59:09 | Re: Memcached for Database server |