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
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
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
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,
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,
> 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.
