From: | InfraRED/Veres Tibor <infrared(at)a-b(dot)hu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] [GENERAL] when are indexes used? |
Date: | 1999-09-23 15:45:01 |
Message-ID: | XFMail.990923174501.infrared@a-b.hu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> explain select * from auth order by uid;
>> Sort (cost=2.06 rows=32 width=40)
>> -> Seq Scan on auth (cost=2.06 rows=32 width=40)
>
> With only 32 rows in the table, I suspect the machine is making the
> right choices here. (If you actually have more than 32 rows then you
> need to vacuum to update the stats...) Index scans are not some sort of
> free magic solution; they cost a lot more per row scanned than
> sequential scans. They aren't necessarily cheaper than a sequential
> scan plus in-memory sort, either.
I did't know about these guesses, and I provided these only for example.. My
real problem is with a ~6000 row database and a select * ... order by query
which takes more than 5 sec. The same query runs for less than 0.1 sec on mssql
:-((
--
InfraRED of aurora-borealis/Veres Tibor
E-Mail: infrared(at)a-b(dot)hu
From | Date | Subject | |
---|---|---|---|
Next Message | Adriaan Joubert | 1999-09-23 16:20:49 | Re: [HACKERS] Re: [GENERAL] Update of bitmask type |
Previous Message | Bruce Momjian | 1999-09-23 15:39:18 | Re: [HACKERS] Operator definitions |