On 7/22/07, Vincenzo Romano <[EMAIL PROTECTED]> wrote:
On Sunday 22 July 2007 19:20:08 Tom Lane wrote:
> Vincenzo Romano <[EMAIL PROTECTED]> writes:
> > In the original setup, the "UNIQUE" constraint had been dropped
> > *before* doing the tests. So the "slow" case is without the
> > UNIQUE const
Vincenzo Romano <[EMAIL PROTECTED]> writes:
> On Sunday 22 July 2007 19:20:08 Tom Lane wrote:
>> With what index, pray tell?
> In the original setup, the "UNIQUE" constraint had been dropped
> *before* doing the tests. So the "slow" case is without the
> UNIQUE constraint but with an index on NOT
On Sunday 22 July 2007 19:20:08 Tom Lane wrote:
> Vincenzo Romano <[EMAIL PROTECTED]> writes:
> > In the original setup, the "UNIQUE" constraint had been dropped
> > *before* doing the tests. So the "slow" case is without the
> > UNIQUE constraint but with an index. The NOT NULL was instead
> > the
Vincenzo Romano <[EMAIL PROTECTED]> writes:
> In the original setup, the "UNIQUE" constraint had been dropped
> *before* doing the tests. So the "slow" case is without the UNIQUE
> constraint but with an index. The NOT NULL was instead there.
With what index, pray tell?
re
On Saturday 21 July 2007 08:00:11 Tom Lane wrote:
> "Josh Tolley" <[EMAIL PROTECTED]> writes:
> > Might it just be that the original UNIQUE + NOT NULL index was
> > bloated or otherwise degraded, and reindexing it would have
> > resulted in the same performance gain? That's just a guess.
>
> Yeah.
Hi all.
Maybe mine is a stupid question, but I'd like to know the answer if
possible.
In an inner join involving a 16M+ rows table and a 100+ rows table
performances got drastically improved by 100+ times by replacing a
UNIQUE-NOT NULL index with a PRIMARY KEY on the very same columns in
the ver
"Josh Tolley" <[EMAIL PROTECTED]> writes:
> Might it just be that the original UNIQUE + NOT NULL index was bloated
> or otherwise degraded, and reindexing it would have resulted in the
> same performance gain? That's just a guess.
Yeah. There is precious little difference between UNIQUE+NOT NULL
On 7/20/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
On Jul 20, 2007, at 17:54 , Vincenzo Romano wrote:
> In an inner join involving a 16M+ rows table and a 100+ rows table
> performances got drastically improved by 100+ times by replacing a
> UNIQUE-NOT NULL index with a PRIMARY KEY on th
On Jul 20, 2007, at 17:54 , Vincenzo Romano wrote:
In an inner join involving a 16M+ rows table and a 100+ rows table
performances got drastically improved by 100+ times by replacing a
UNIQUE-NOT NULL index with a PRIMARY KEY on the very same columns in
the very same order. The query has not be
Hi all.
Maybe mine is a stupid question, but I'd like to know the answer if
possible.
In an inner join involving a 16M+ rows table and a 100+ rows table
performances got drastically improved by 100+ times by replacing a
UNIQUE-NOT NULL index with a PRIMARY KEY on the very same columns in
the ver
10 matches
Mail list logo
