On Fri, Apr 13, 2007 at 12:42:36PM -0400, Joe wrote:
>
> Just curious: is there a way to defeat MVCC?
No. That is,
> i.e., if you can lock the
> database exclusively, there won't be any readers or writers?
while this is true, it doesn't shut off the way writes go through the
system. MVCC i
Hi Andrew,
On Fri, 2007-04-13 at 07:49 -0400, Andrew Sullivan wrote:
> Because in the general case, you need the intermediate rows. The
> problem is that you'd have to write a special piece of code to catch
> the case where nobody else can see the row that you're about to
> expire, and that test
On Fri, Apr 13, 2007 at 07:49:19AM -0400, Andrew Sullivan wrote:
> On Fri, Apr 13, 2007 at 09:02:58AM +0800, John Summerfield wrote:
> > 1. For the first day or so, my observation was that the disk was not
> > particularly busy.
>
> That's completely consistent with the theory I have. As the num
On Fri, Apr 13, 2007 at 09:02:58AM +0800, John Summerfield wrote:
>
> Why is this implementation preferable to not doing that?
Because this way, readers never wait for writers. On most database
systems, that pending UPDATE would block anyone reading the row too,
even if they weren't going to wri
Andrew Sullivan wrote:
On Wed, Apr 11, 2007 at 10:23:34PM +0800, John Summerfield wrote:
Each row's identified by a key, and the key doesn't change.
That doesn't matter.
ADABAS would put the updated record right back where it came from, it
That isn't how PostgreSQL works.
I'm having
On Wed, Apr 11, 2007 at 10:23:34PM +0800, John Summerfield wrote:
> Each row's identified by a key, and the key doesn't change.
That doesn't matter.
> ADABAS would put the updated record right back where it came from, it
That isn't how PostgreSQL works.
I'm having a hard time laying my hands on
Andrew Sullivan wrote:
On Wed, Apr 11, 2007 at 05:54:45AM +0800, John Summerfield wrote:
Linux caches writes, I don't think it should be hitting disk at all. The
I _sure hope_ you don't care about this data, then. That's not a
real safe way to work. But. . .
As I said in the first place, t
On Wed, Apr 11, 2007 at 05:54:45AM +0800, John Summerfield wrote:
> Linux caches writes, I don't think it should be hitting disk at all. The
I _sure hope_ you don't care about this data, then. That's not a
real safe way to work. But. . .
> table being updated contains records 7482 (658K raw dat
Andrew Sullivan wrote:
On Wed, Apr 11, 2007 at 12:41:23AM +0800, John Summerfield wrote:
The Linux kernel's clearly doing a lot of work, and the disk supports
You might also be into context-switch hell. What processor, which
kernel, and which Postgres version again?
on opensuse 10.2 (the la
On Wed, Apr 11, 2007 at 12:41:23AM +0800, John Summerfield wrote:
> The Linux kernel's clearly doing a lot of work, and the disk supports
You might also be into context-switch hell. What processor, which
kernel, and which Postgres version again?
> >>For each record, I update a non-key field in
Andrew Sullivan wrote:
On Tue, Apr 03, 2007 at 10:16:13PM +0800, John Summerfield wrote:
It is hitting the disk pretty hard now on this machine, but the laptop's
still going too, and the disk seems to run about half the time, part of
a second running, part idle (but the intervals are getting sh
On Tue, Apr 03, 2007 at 10:16:13PM +0800, John Summerfield wrote:
> It is hitting the disk pretty hard now on this machine, but the laptop's
> still going too, and the disk seems to run about half the time, part of
> a second running, part idle (but the intervals are getting shorter).
>
> It str
I have a Java (java 1.1) program that I wrote some years ago, to read
records from a text file and insert it into a ostgresql database.
One of the assumptions I made was that one file contained one day's
data, maybe as many as 1500 records, and I coded it to do the whole lot
as one transaction
13 matches
Mail list logo
