Hi,
Indeed, setting random_page_cost does the trick. Thanks!
It seems to make sense to set random_page_cost to this value. Are there any
drawbacks?
postgresql-7.3.4
postgresql.conf:
tcpip_socket = true
max_connections = 100
superuser_reserved_connections = 2
# Performance
#
shared_buffers = 12000
sort_mem = 8192
vacuum_mem = 32768
effective_cache_size = 64000
random_page_cost = 2
...
--On söndag, september 28, 2003 14.34.25 -0700 Josh Berkus
<josh@agliodbs.com> wrote:
> Palle,
>
>> I have a SQL statement that I cannot get to use the index. postgresql
>> insists on using a seqscan and performance is very poor. set
>> enable_seqscan = true boost performance drastically, as you can see
>> below. Since seqscan is not always bad, I'd rather not turn it off
>> completely, but rather get the planner to do the right thing here. Is
>> there another way to do this, apart from setting enable_seqscan=false?
>
> In your postgresql.conf, try setting effective_cache_size to something
> like 50% of your system's RAM, and lovering random_page_cost to 2.0 or
> even 1.5. Then restart PostgreSQL and try your query again.
>
> What version, btw?
>
>
> --
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
