Palle,
> 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?
Only if your server was heavily multi-tasking, and as a result had little
RAM+CPU available. Then you'd want to raise the value again.
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_buffe
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 r
Hi!
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 ge
As others have mentioned, you really ought to get battery-backed cache if
you're doing any volume of writes. The ability to do safe write-back
caching makes an *insane* difference to write performance.
The site you link to also has that for only 15% more money:
http://uk.azzurri.com/product/produ
On Sunday 28 September 2003 09:19, David Griffiths wrote:
> No difference. Note that all the keys that are used in the joins are
> numeric(10)'s, so there shouldn't be any cast-issues.
Can you make them bigint and see? It might make some difference perhaps.
Checking the plan in the meantime.. BTW
