Christopher Kings-Lynne wrote:
> > > Af far as I know Oracle doesn't have any short cut (along the lines of
> > > what is being discussed in this thread) for this operation. However
> > > Oracle is more efficient in providing the answer than postgres
> > currently
> > > is. While postgres needs
> > Af far as I know Oracle doesn't have any short cut (along the lines of
> > what is being discussed in this thread) for this operation. However
> > Oracle is more efficient in providing the answer than postgres
> currently
> > is. While postgres needs to perform a full scan on the table, Orac
Tom Lane wrote:
>
> Doug McNaught <[EMAIL PROTECTED]> writes:
> > "Dann Corbit" <[EMAIL PROTECTED]> writes:
> >> It would be nice if total table cardinality could be maintained live.
>
> > How would this work with MVCC?
>
> It wouldn't. That's why it's not there. Under MVCC, table cardinality
On Fri, 5 Apr 2002, Barry Lind wrote:
> Af far as I know Oracle doesn't have any short cut (along the lines of
> what is being discussed in this thread) for this operation. However
> Oracle is more efficient in providing the answer than postgres currently
> is. While postgres needs to perfor
> AFAICS, making them exact would not improve the planning estimates
> at all, because there are too many other sources of error. We have
> approximate stats already via vacuum/analyze statistics gathering.
> >>
> What happens if someone deletes 75% of a table?
> What happens if someone imports 3
Af far as I know Oracle doesn't have any short cut (along the lines of
what is being discussed in this thread) for this operation. However
Oracle is more efficient in providing the answer than postgres currently
is. While postgres needs to perform a full scan on the table, Oracle
will only n
> In addition, this seems to be the "canonical paper" on snapshot
> isolation:
>
> http://citeseer.nj.nec.com/berenson95critique.html
There is an excellent, more recent paper, Generalized Isolation Level
Definitions (http://citeseer.nj.nec.com/adya00generalized.html).
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 3:42 PM
To: Peter Bierman
Cc: Dann Corbit; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Peter Bierman <[EMAIL PROTECTED]> writes:
> ... Your comment: "
Peter Bierman <[EMAIL PROTECTED]> writes:
> ... Your comment: "An
> accurate cardinality figure can greatly enhance the optimizer's
> ability to perform joins in the correct order" was intriguing, and I'd
> be interested in Tom's thoughts on just that bit.
Approximate figures are quite sufficient
> I don't think your idea would work for a concurrent user setup where
> people have different transactions started at different times with
> different amounts of changes inside each transaction.
>
> That's why it would have to be tracked on a "per connection" basis for
> all the tables.
I tried
(Sorry that my previous post did not reach the pgsql-hackers list, I
sent it from the wrong address and was thus not considered a
subscriber)
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> But I am a bit puzzled. How can a serializable transaction be
> performed in a MVCC system? I realize the Or
> >> It would be nice if total table cardinality could be maintained live.
> >
> > How would this work with MVCC?
>
> It wouldn't. That's why it's not there. Under MVCC, table cardinality
> is in the eye of the beholder...
That makes me curious how oracle implements it. I was under the impressi
-Original Message-
From: Rod Taylor [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 12:35 PM
To: Dann Corbit; Tom Lane
Cc: Doug McNaught; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Not to mention it only increases the speed of:
SELECT count(*) FROM
At 12:08 PM -0800 4/5/02, Dann Corbit wrote:
>I guess that this model can be viewed as "everything is a snapshot".
>It seems plain that the repercussions for a data warehouse and for
>reporting have not been thought out very well. This is definitely
>very, very bad in that arena. I suppose that
-Original Message-
From: Jon Grov [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 12:54 PM
To: Dann Corbit
Cc: Mike Mascari; Doug McNaught; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> That
-Original Message-
From: Mike Mascari [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 12:44 PM
To: Dann Corbit
Cc: Doug McNaught; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Dann Corbit wrote:
>
> I guess that this model can be viewed as "ever
Dann Corbit wrote:
>
> I guess that this model can be viewed as "everything is a snapshot".
> It seems plain that the repercussions for a data warehouse and for
> reporting have not been thought out very well. This is definitely
> very, very bad in that arena. I suppose that reporting could sti
yours. You cannot imagine why you ever felt
otherwise.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Dann Corbit" <[EMAIL PROTECTED]>
Cc: "Doug McNaught" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, April
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> At any rate, there is clearly a concept of cardinality in any case.
Certainly. The count(*) value is perfectly well defined within any one
transaction. We *could*, if we wanted to, implement bookkeeping logic
that would keep track of the number of row
-Original Message-
From: Doug McNaught [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 11:55 AM
To: Dann Corbit
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> How would this work with MVCC
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> How would this work with MVCC?
> >>
> Whenever a commit occurs, the pending inserts are totaled into the sum
> and the pending deletes are subtracted. It can be a list in memory or
> whatever. Maybe you are referring to the old (expired) rows begin
>
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> If this is true (even after a commit) then MVCC is a very bad thing. No
> transactions occur, and two people ask the same question yet get
> different answers. Doesn't that scare anyone? That would mean (among
> other things) that Postgresql cannot b
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> How many accounts are 90 days overdue? Bill says 78 and Frank says 82.
> Who is right and how can we know?
If Bill and Frank look at exactly the same instant (ie, from read-only
transactions started at the same time), they will get the same answer.
If
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 11:37 AM
To: Doug McNaught
Cc: Dann Corbit; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Doug McNaught <[EMAIL PROTECTED]> writes:
> "Dann Corbit" <[EM
-Original Message-
From: Doug McNaught [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 11:30 AM
To: Dann Corbit
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> It would be nice if total tabl
Doug McNaught <[EMAIL PROTECTED]> writes:
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
>> It would be nice if total table cardinality could be maintained live.
> How would this work with MVCC?
It wouldn't. That's why it's not there. Under MVCC, table cardinality
is in the eye of the beholder...
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> It would be nice if total table cardinality could be maintained live.
> So (after the initial vacuum) we update the cardinality for each table
> in the system table (or perhaps add an entry to the table itself).
> There are two reasons why this is an im
It would be nice if total table cardinality could be maintained live.
So (after the initial vacuum) we update the cardinality for each table
in the system table (or perhaps add an entry to the table itself).
There are two reasons why this is an important optimization. Firstly,
it is a psychologic
28 matches
Mail list logo
