From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Guillaume Cottenceau <gc(at)mnc(dot)ch> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Poor performance on seq scan |
Date: | 2006-09-12 13:24:24 |
Message-ID: | 4506B508.80806@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Guillaume Cottenceau wrote:
> Laszlo Nagy <gandalf 'at' designaproduct.biz> writes:
>
>>> Probably, but PostgreSQL doesn't know how to do that. Even if it
>>> did, it depends on how many matches there is. If you scan the index
>>> and then fetch the matching rows from the heap, you're doing random
>>> I/O to the heap. That becomes slower than scanning the heap
>>> sequentially if you're going to get more than a few hits.
>>>
>> I have 700 000 rows in the table, and usually there are less than 500
>> hits. So probably using a "seq index scan" would be faster. :-) Now I
>>
>
> You can confirm this idea by temporarily disabling sequential
> scans. Have a look at this chapter:
>
I don't think it will anyway do a "seq index scan" as Laszlo envisions.
PostgreSQL cannot do "fetch index tuple and apply %Mug% to it. If it
matches, fetch heap tuple". Even if you disable sequential scans, it's
still going to fetch every heap tuple to see if it matches "%Mug%". It's
just going to do it in index order, which is slower than a seq scan.
BTW: in addition to setting enable_seqscan=false, you probably have to
add a dummy where-clause like "name > ''" to force the index scan.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-09-12 13:32:55 | Re: Poor performance on seq scan |
Previous Message | Guillaume Cottenceau | 2006-09-12 12:46:18 | Re: Poor performance on seq scan |