Re: Again, sorry, caching.

From: Greg Copeland <greg(at)CopelandConsulting(dot)Net>
To: mlw <markw(at)mohawksoft(dot)com>
Cc: "Mattew T(dot) O'Connor" <matthew(at)www2(dot)us(dot)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Again, sorry, caching.
Date: 2002-03-18 15:40:05
Message-ID: 1016466005.14670.27.camel@mouse.copelandconsulting.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

>
> >The primary use that you have suggested is for web sites,
> > and they certainly won't mind of the cache is 0.3seconds out of date.
>
> Again, if they don't care about accuracy, then they will use MySQL. PostgreSQL
> is a far better system. Making PostgreSQL less accurate, less "correct" takes
> away, IMHO, the very reasons to use it.
>

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.

I tend to agree with Mettew. Granted, there are some application
domains where this can be critical...generally speaking, web serving
isn't one of them.

That's why all of the solutions I offered were pointedly addressing a
web server scenario and not a generalized database cache. I completely
agree with you on that. In a generalized situation, the database should
be managing and caching the data (which it already does).

Greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message mlw 2002-03-18 16:08:11 Re: Again, sorry, caching.
Previous Message Tom Lane 2002-03-18 15:29:10 Re: postgres is not using tas