e linux machine has 756Mb RAM and a setting of 3000 shared
memory pages (max. shared memory allocation of 32Mb). I can't see any
other differences in configuration.
Disk throughput on both is reasonable (40Mb/second buffered reads)
Can anyone explain the difference in the planner behaviour on th
Linux-specific instructions.
Thanks for the link.
Are you saying that the shared memory size is the issue here? Please
can you explain how it would cause a seq scan rather than an index
scan.
I would like to understand the issue before making changes.
--
Simon Godden
---(
rmine the collating sequence?
I'm not too familiar with unix locale issues - does this output match
your problem description?
Can you explain how to change my locale to 'C'? (I'm quite happy for
you to tell me to RTFM, as I know this is not a linux user mailing
list :)
--
Simon Godden
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On 10/4/06, Richard Huxton wrote:
simon godden wrote:
From psql, a "show all" command will list all your config settings and
let you check the lc_xxx values are correct.
lc_collate is C, as are all the other lc settings.
I have run the analyze commands.
Still the same.
--
Si
t of it - how's that?)
The difference seems to be whether it is treating the index condition
as 'character varying' or 'text'.
Basically, can I do > < >= <= on a varchar without causing a seq-scan?
--
Simon Godden
---(end of broadcast)---
TIP 6: explain analyze is your friend
I think I am being stupid now.
The > query was returning so many rows (87% of the rows in the table)
that a seq-scan was of course the best way.
Sorry - all is now working and the problem was the locale issue.
Thanks so much for your help everyone.
--
Simon God
