I think you're just witnessing the optimizer at work. If it thinks that
doing sequential scans is faster, it will ignore the indices.
At 11:03 AM 5/31/2001 +0200, Koen Antonissen wrote:
>Thing I descovered after i posted to the group was that after creating
>the scheme again, the indexes are us
It really depends on the number of rows. If the number of
rows in the tables are small or the number of rows returned is
a reasonable percentage, the index scan is currently more expensive.
What does (for example) select count(*) from classes; give?
On Thu, 31 May 2001, Koen Antonissen wrote:
nalyze) the use
of indexes was gone again on certain tables...
Any other suggestions?
-Original Message-
From: bernd pinter [mailto:[EMAIL PROTECTED]]
Sent: donderdag 31 mei 2001 8:53
To: Koen Antonissen
Subject: Re: [SQL] primary key scans in sequence
the problem is the optimizer.
you u
On Wed, 30 May 2001, Koen Antonissen wrote:
> Now this one doesn't:
> Table "teams"
> Attribute | Type | Modifier
> ---+-+--
> id| integer | not null
Scan on teams (cost=0.00..1.09 rows=1 width=173)
EXPLAIN
I really don't understand the difference between the two, and it didn't
work before i created an extra index on id...
Kind regards,
Koen Antonissen
-Original Message-----
From: Richard Poole [mailto:[EMAIL PROTECTED]]
bernd writes:
> hey i have the following table def (834.000 rows, vaccum analyze'd):
> dl_online=# \d mitglied
> Table "mitglied"
>Attribute| Type | Modifier
> +--+
> mitgliedid | bigint
On Thu, Mar 29, 2001 at 03:47:58PM +0200, bernd wrote:
> hey i have the following table def (834.000 rows, vaccum analyze'd):
> dl_online=# \d mitglied
> Table "mitglied"
>Attribute| Type | Modifier
> +--+--
hey i have the following table def (834.000 rows, vaccum analyze'd):
dl_online=# \d mitglied
Table "mitglied"
Attribute| Type | Modifier
+--+
mitgliedid | bigint | not null
dlnummer
