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
Some questions for you at the end of this Tom...which I'd been thinking
about...and you touched on...hey, you did tell me to ask! :)
On Sat, 2002-03-16 at 14:38, Tom Lane wrote:
Greg Copeland [EMAIL PROTECTED] writes:
I'm talking about something that would be optional. So, what's the cost
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
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
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
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
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
On Tue, 2002-03-19 at 15:30, Matthew Kirkwood wrote:
On Tue, 19 Mar 2002, Oleg Bartunov wrote:
Sorry to reply over you, Oleg.
On 13 Mar 2002, Greg Copeland wrote:
One of the reasons why I originally stated following the hackers list is
because I wanted to implement bitmap indexes
On a side note, I thought I would mention that the Next Generation POSIX
Threading (NGPT) Project (IBM --
http://www-124.ibm.com/developerworks/projects/pthreads) patches have
just been accepted to the 2.5.x Linux kernel. A 2.4.x patch is also
available. So, it may be possible that POSIX
What if we used a combination of the two approaches? That is, when an
overflow occurs, overflow into a table? That way, nothing is lost and
spurious random events don't have to occur. That way, things are faster
when overflows are not occurring. When the system gets too far behind,
it simply
It doesn't really say, however, it makes me wonder if it's SGI's KAIO
(http://oss.sgi.com/projects/kaio/) effort which is reported to provide
up to 35% performance improvement for heavily I/O bound applications.
Again, I'm not sure it is SGI's effort that is being talked about here,
nonetheless,
Cool. Thanks for the information. The only other PAIO effort that I
knew of was the glibc user space effort...
Greg
On Sat, 2002-03-30 at 12:36, Neil Conway wrote:
On Sat, Mar 30, 2002 at 09:59:11AM -0600, Greg Copeland wrote:
It doesn't really say, however, it makes me wonder if it's
201 - 213 of 213 matches
Mail list logo
