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
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:
> > 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 tran
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 i
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
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 thin
Jeff Davis <[EMAIL PROTECTED]>,
PostgreSQL-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
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
On Tue, 2002-03-19 at 21:40, Christopher Kings-Lynne wrote:
> 1. Implementing a byte-compatible query cache WILL improve the speed of
> repetitive queries over static data.
For some specific workloads, I think it has the potential to
significantly improve performance.
> 3. It is really hard to i
> > Well, the simple query cache scheme that is currently being proposed
> > would use a byte-by-byte comparison of the incoming query. I think the
> > consensus is that for a lot of workloads, this would be a bad idea.
>
> And this is what I have been trying to argue. Many SQL
> deployments execu
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 that is currently being propose
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 compari
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 da
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 project
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.
>
> But can't this be achieved by using a LISTEN/NOTIFY mo
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 cach
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
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. It should be possible, but require a lot of research, to enable
> > the function manager to return a set
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. On
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
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
On a side note, is it possible that we could add the "iscachable" which
for now, would give cache bias? That is, allow for a mechanism to
indicate that the pages that are required for this query will be
frequently needed. I've not looked at the buffer cache implementation.
Is it possible to som
> 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 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 fixi
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 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 sim
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
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. Post
"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 applicat
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
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 c
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 broadcast)---
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 a
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.
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 but
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.
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
> > dyn
> 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
> ca
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
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
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 a
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 t
I traded a couple emails with a guy using one of my open source projects. To
make a long story short, he is going to the new version of MySQL for his
website because of the new caching feature. He is convinced that it will speed
up his web site, and he is probably right.
On a web site, a few spec
43 matches
Mail list logo
