Greg Copeland wrote:
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,
Bruce Momjian [EMAIL PROTECTED] writes:
Also, on the NOTIFY/trigger idea, triggers are called on statement end,
not transaction end, so if an UPDATE query is in a multi-statement
transaction, another backend looking for the NOTIFY will receive it
before the transaction commits, meaning it
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Also, on the NOTIFY/trigger idea, triggers are called on statement end,
not transaction end, so if an UPDATE query is in a multi-statement
transaction, another backend looking for the NOTIFY will receive it
before the transaction
Bruce Momjian [EMAIL PROTECTED] writes:
No it won't.
Is this because NOTIFY is held for transaction end or because the
triggers are held until transaction commit?
The former.
regards, tom lane
---(end of broadcast)---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
No it won't.
Is this because NOTIFY is held for transaction end or because the
triggers are held until transaction commit?
The former.
Thanks. I see it in the NOTIFY manual page now. Very nice.
--
Bruce Momjian
mlw wrote:
Jan Wieck wrote:
mlw wrote:
[...]
IMHO modifying the function manager to allow the return of a full row, and a
set of full rows, answers a LOT of issues I have seen over the years with
PostgreSQL extensibility.
Sure. Actually I think you'll have an easy
-development [EMAIL PROTECTED]
Subject: Re: [HACKERS] Again, sorry, caching, (Tom What do you think: function
On 19 Mar 2002, Greg Copeland wrote:
On Tue, 2002-03-19 at 07:46, mlw wrote:
[snip]
Right now, the function manager can only return one value, or one set of values
for a column
On Tue, Mar 19, 2002 at 08:28:19PM -0500, Neil Conway wrote:
On Tue, 2002-03-19 at 19:20, F Harvell wrote:
I feel that the caching should be SQL transparent. If it is
implemented reasonably well, the performance gain should be pretty
much universal.
Well, the simple query cache scheme
Neil Conway [EMAIL PROTECTED] writes:
My impression (I could be wrong) is that LISTEN/NOTIFY doesn't get
the press that it deserves. If this model isn't widely used because
of some deficiencies in the LISTEN/NOTIFY implementation, IMHO our
time would be better spent fixing those problems than
Yes...I was thinking that a generic library interface with a nice design
pattern might meet this need rather well. Done properly, I think we can
make it where all that, more or less, would be needed is application
hooks which accept the result set to be cached and a mechanism to signal
On Tue, 2002-03-19 at 07:46, mlw wrote:
[snip]
Right now, the function manager can only return one value, or one set of values
for a column. It should be possible, but require a lot of research, to enable
the function manager to return a set of rows. If we could get that working, it
could be
On Tue, 2002-03-19 at 07:46, mlw wrote:
I was thinking about this. There seems to be a consensus that caching means no
ACID compliance. And everyone seems to think it needs to be limited. We can
implement a non-ACID cache as a contrib function with some work to the function
manager.
Until
Jeff Davis [EMAIL PROTECTED] writes:
A library implies that the application is running long enough to actually
hear the notofication. Web apps start up, read from the database, and before
any cache is needed they're done and the next one starts up, reading again
from the database. Only
Gavin Sherry wrote:
I'm not sure that cached results is a direction postgres need move in. But
if it does, I think this a better way to do it (given that I may have
overlooked something) than modifying the function manager (argh!).
I actually had an anterior motive.
Your comment about
On Tue, 19 Mar 2002 12:12:52 CST, Ross J. Reedstrom wrote:
On Mon, Mar 18, 2002 at 09:35:51PM -0500, Neil Conway wrote:
It is an application issue
This is completely wrong. Caching can not be done against a database without
knowledge of the database, i.e. when the data changes.
On Tue, 2002-03-19 at 19:20, F Harvell wrote:
I feel that the caching should be SQL transparent. If it is
implemented reasonably well, the performance gain should be pretty
much universal.
Well, the simple query cache scheme that is currently being proposed
would use a byte-by-byte
On Sat, Mar 16, 2002 at 09:01:28AM -0500, mlw wrote:
If it is mostly static data, why not just make it a static page?
Because a static page is a maintenance nightmare. One uses a database in a web
site to allow content to be changed and upgraded dynamically and with a minimum
of work.
It's
Karel Zak wrote:
On Sat, Mar 16, 2002 at 09:01:28AM -0500, mlw wrote:
If it is mostly static data, why not just make it a static page?
Because a static page is a maintenance nightmare. One uses a database in a web
site to allow content to be changed and upgraded dynamically and with a
Le Lundi 18 Mars 2002 13:23, mlw a écrit :
Lets face it, MySQL wins a lot of people because they put in features that
people want.
MySQL is very interested in benchmarks.
It does not really care for data consistency.
Cheers, Jean-Michel POURE
---(end of
Yes. EVERY person that I've ever known which runs MySQL run for two
very simple reasons. First, they believe it to be wicked fast. Second,
they don't understand what ACID is, what a transaction is, or why
running a single session against a database to perform a benchmark is a
completely bogus
Jean-Michel POURE wrote:
Le Lundi 18 Mars 2002 13:23, mlw a écrit :
Lets face it, MySQL wins a lot of people because they put in features that
people want.
MySQL is very interested in benchmarks.
It does not really care for data consistency.
In no way am I suggesting we avoid ACID
Mattew T. O'Connor wrote:
My big problem with putting the cache outside of the database is that it is
now incumbent on the applications programmer to write a cache. A database
should manage the data, the application should handle how the data is
presented. Forcing the application to
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
Greg Copeland wrote:
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
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
On Sat, 2002-03-16 at 09:01, mlw wrote:
On a web site, a few specific queries get executed, unchanged, repeatedly.
Think about an ecommerce site, most of the time it is just a handful of basic
queries. These basic queries are usually against pretty large product tables. A
caching mechanism
On Mon, 2002-03-18 at 20:35, Neil Conway wrote:
[snip]
My impression (I could be wrong) is that LISTEN/NOTIFY doesn't get the
press that it deserves. If this model isn't widely used because of some
deficiencies in the LISTEN/NOTIFY implementation, IMHO our time would be
better spent fixing
Andrew Sullivan wrote:
On Sat, Mar 16, 2002 at 09:01:28AM -0500, mlw wrote:
If it is mostly static data, why not just make it a static page?
Because a static page is a maintenance nightmare. One uses a
database in a web site to allow content to be changed and upgraded
dynamically and
Greg Copeland wrote:
On Sat, 2002-03-16 at 08:36, mlw wrote:
Triggers and asynchronous notification are not substitutes for real hard ACID
complient caching. The way you suggest implies only one access model. Take
the
notion of a library, they have both web and application access. These
I think the notion that data is managed outside of the database is bogus. Query
caching can improve performance in some specific, but popular, scenarios.
Saying it does not belong within the database and is the job of the
application, is like saying file caching is not a job of the file system
I previously replied to you vaguely describing a way you could implement
this by using a combination of client side caching and database tables
and triggers to allow you to determine if your cache is still valid.
Someone came right behind me, Tom maybe??, and indicated that the
proper/ideal way
Triggers and asynchronous notification are not substitutes for real hard ACID
complient caching. The way you suggest implies only one access model. Take the
notion of a library, they have both web and application access. These should
both be able to use the cache.
Also, your suggestion does not
On Sat, 2002-03-16 at 08:01, mlw wrote:
[snip]
If it is mostly static data, why not just make it a static page?
Because a static page is a maintenance nightmare. One uses a database in a web
site to allow content to be changed and upgraded dynamically and with a minimum
of work.
Oh ya, I
On Sat, 2002-03-16 at 08:36, mlw wrote:
Triggers and asynchronous notification are not substitutes for real hard ACID
complient caching. The way you suggest implies only one access model. Take the
notion of a library, they have both web and application access. These should
both be able to use
I was thinking that it could be implemented as a keyword or comment in a query.
Such as:
select * from table where column = 'foo' cacheable
or
select * from table where column = 'bar' /* cacheable */
Having caching within PostgreSQL will be good for data integrity. Application
caches
35 matches
Mail list logo
