On Sun, 5 May 2002 [EMAIL PROTECTED] wrote:
> On Sun, 05 May 2002 10:01:57 EDT, the world broke into rejoicing as
> mlw <[EMAIL PROTECTED]> said:
> > It is sunday morning and I have been musing about some PostgreSQL issues. As
> > some of you are aware, my dot com, dot died, and I am working on
...
> (1) Major version upgrade. This is a hard one, having to dump out and restore a
> database to go from 7.1 to 7.2 or 7.2 to 7.3 is really a hard sell.
Hmm, maybe it would be more acceptable if we charged $40k per license,
but refunded $40k if you *want* to dump/reload. Gets that motivation
l
I said:
> On the other hand --- if the index *is* unique, and we are checking
> equality on all columns (a fairly easily checked condition), then we
> know we should retrieve at most one visible tuple. So, without making
> any incorrect assumptions, we could terminate the indexscan after the
> fi
Tom Lane wrote:
> No. For starters, we couldn't guarantee that insertion order is the
> same as transaction commit order. Even if we did, your assumption
> that commit order is the same as visibility is too simplistic. And
> none of this works if the index isn't unique.
Ahh, I get it, (again,
On Mon, 06 May 2002 00:50:25 +1000, the world broke into rejoicing as
Gavin Sherry <[EMAIL PROTECTED]> said:
> On Sun, 5 May 2002 [EMAIL PROTECTED] wrote:
> > On Sun, 05 May 2002 10:01:57 EDT, the world broke into rejoicing as
> > mlw <[EMAIL PROTECTED]> said:
> > > It is sunday morning and I ha
I said:
> none of this works if the index isn't unique.
On the other hand --- if the index *is* unique, and we are checking
equality on all columns (a fairly easily checked condition), then we
know we should retrieve at most one visible tuple. So, without making
any incorrect assumptions, we cou
mlw <[EMAIL PROTECTED]> writes:
> I guess I don't understand. Why does it have to visit all of them?
Because it doesn't have any way to know in advance which one(s) are
visible to it.
> If ordering
> them from newest tom oldest, and then take the first transaction ID that it
> smaller then curre
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > [Index] --> [Target]->[LRU]->[1]->[2]->[3]->[MRU]
>
RE: http://archives.postgresql.org/pgsql-hackers/2002-05/msg00030.php
There are a few variations, but it seems I am making the same assumptions as
Lincln Yeoh. So, you are saying that wh
mlw <[EMAIL PROTECTED]> writes:
> [Index] --> [Target]->[LRU]->[1]->[2]->[3]->[MRU]
This diagram is entirely unrelated to reality. See, eg,
http://archives.postgresql.org/pgsql-hackers/2002-05/msg00012.php
regards, tom lane
---(end of broadcast)-
On Sun, 5 May 2002 [EMAIL PROTECTED] wrote:
> On Sun, 05 May 2002 10:01:57 EDT, the world broke into rejoicing as
> mlw <[EMAIL PROTECTED]> said:
> > It is sunday morning and I have been musing about some PostgreSQL issues. As
> > some of you are aware, my dot com, dot died, and I am working on
On Sun, 05 May 2002 10:01:57 EDT, the world broke into rejoicing as
mlw <[EMAIL PROTECTED]> said:
> It is sunday morning and I have been musing about some PostgreSQL issues. As
> some of you are aware, my dot com, dot died, and I am working on a business
> plan for a consulting company which, amo
It is sunday morning and I have been musing about some PostgreSQL issues. As
some of you are aware, my dot com, dot died, and I am working on a business
plan for a consulting company which, amongst other things, will feature
PostgreSQL. As I am working on the various aspects, some issue pop up abo
12 matches
Mail list logo
