Re: Again, sorry, caching. - Mailing list pgsql-hackers

On Mon, 2002-03-18 at 10:08, mlw wrote:
> Greg Copeland wrote:
> >
> > On Mon, 2002-03-18 at 08:15, mlw wrote:
> > > "Mattew T. O'Connor" wrote:
> > > >
[snip]

> >
> > If you are using a web site and you need real time data within 0.3s,
> > you've implemented on the wrong platform.  It's as simple as that.  In
> > the web world, there are few applications where a "0.3s" of a window is
> > notable.  After all, that "0.3s" of a window can be anywhere within the
> > system, including the web server, network, any front end caches, dns
> > resolutions, etc.
>
> This is totally wrong! An out of date cache can cause errors by returning
> results that are no longer valid, thus causing lookup issues. That is what ACID
> compliance is all about.

I understand what ACID is about.  Question.  Was the result set valid
when it was cached?  Yes.  So will it be valid when it's returned as a
cached result set?  Yes.  Might it be an out of date view.  Sure...with
a horribly small window for becoming "out of date".  Will it cause look
up problems?  Might.  No more than what you are proposing.  In the mean
time, the FE cached result set, performance wise, is beating the pants
off of the database cached solution on both a specific work load and
over all system performance.

I should point out that once the FE cache has been notified that it's
cache is invalid, the FE would no longer return the invalidated result
set.  I consider that to be a given, however, from some of your comments
I get the impression that you think the invalid result set would
continue to be served.  Another way of thinking about that is...it's
really not any different from the notification acting as the result
returned result set...from a validity perspective.  That is...if that
had been the returned result set (the notification) from the
database...it would be accurate (which in the case means the FE cache is
now dirty and treated as such)...if the query is refreshed because it is
now invalid..the result set is once again accurate and reflective of the
database.

Example...


Database cache
Query result set    Result set returned (cached on database)    local change to database (result set cache invalid)
new query based on out of date queried result set


Application cache
Query result set (cached)    Result set returned    local change to database (app cache invalid and signaled)
new query based on out of date queried result set

Both have that problem since transactional boundaries are hard to keep
across HTTP requests.  This again, is why for web applications, a FE
cache is perfectly acceptable for *most* needs.  Also notice that your
margin for error is more or less the same.

[snip]

> I don't see how caching can be an argument of applicability. I can understand
> it from a time/work point of view, but to debate that it is a useful feature
> seems ludicrous.

I don't think I'm arguing if it's applicable or useful.  Rather, I'm
saying that faster results can be yielded by implementing it in the
client with far less effort than it would take to implement in the BE.
I am arguing that it's impact on overall system performance (though I
really didn't do more than just touch on this topic) is
questionable...granted, it may greatly enhance specific work loads...at
the expense of others.  Which shouldn't be too surprising as trade offs
of some type are pretty common.

At this point in time, I think we've both pretty well beat this topic
up.  Obviously there are two primary ways of viewing the situation.  I
don't think anyone is saying it's a bad idea...I think everyone is
saying that it's easier to address elsewhere and that overall, the net
returns may be at the expense of some other work loads.  So, unless
there are new pearls to be shared and gleaned, I think the topics been
fairly well addressed.  Does more need to said?

Greg