From: | Edoardo Ceccarelli <eddy(at)axa(dot)it> |
---|---|
To: | |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Nick Barr <nicky(at)chuckie(dot)co(dot)uk>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: slow seqscan |
Date: | 2004-04-21 10:10:02 |
Message-ID: | 4086487A.4090703@axa.it |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
tried the
enable_seqscan = false
and I'm having all index scans, timing has improved from 600ms to 18ms
wondering what other implications I might expect.
Edoardo Ceccarelli ha scritto:
>
>> What happens if you go:
>>
>> CREATE INDEX annuncio400_rubric_testo_idx ON annuncio400(rubric,
>> LOWER(testo));
>>
>> or even just:
>>
>> CREATE INDEX annuncio400_rubric_testo_idx ON annuncio400(LOWER(testo));
>>
> I wasn't able to make this 2 field index with lower:
>
> dba400=# CREATE INDEX annuncio400_rubric_testo_idx ON
> annuncio400(rubric, LOWER(testo));
> ERROR: parser: parse error at or near "(" at character 71
>
> seems impossible to creat 2 field indexes with lower function.
>
> The other one does not make it use the index.
>
>
>>> But the strangest thing ever is that if I change the filter with
>>> another one that represent a smaller amount of data it uses the
>>> index scan!!!
>>
>>
>>
>> What's strange about that? The less data is going to be retrieved,
>> the more likely postgres is to use the index.
>>
> can't understand this policy:
>
> dba400=# SELECT count(*) from annuncio400 where rubric='DD';
> count
> -------
> 6753
> (1 row)
>
> dba400=# SELECT count(*) from annuncio400 where rubric='MA';
> count
> -------
> 2165
> (1 row)
>
> so it's using the index on 2000 rows and not for 6000? it's not that
> big difference, isn't it?
>
>
>> I suggest maybe increasing the amount of stats recorded for your
>> rubrik column:
>>
>> ALTER TABLE annuncio400 ALTER rubrik SET STATISTICS 100;
>> ANALYZE annuncio400;
>>
> done, almost the same, still not using index
>
>> You could also try reducing the random_page_cost value in your
>> postgresql.conf a little, say to 3 (if it's currently 4). That will
>> make postgres more likely to use index scans over seq scans.
>>
>
> changed the setting on postgresql.conf, restarted the server,
> nothing has changed.
>
> what about setting this to false?
> #enable_seqscan = true
>
> thanks again
> Edoardo
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2004-04-21 10:15:29 | Re: slow seqscan |
Previous Message | Edoardo Ceccarelli | 2004-04-21 09:41:11 | Re: slow seqscan |