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 Godden
---(
Can you post EXPLAIN ANALYSE for the LIKE and <> queries that should be
using the index? With enable_seqscan on and off please.
OK - I don't know what happened, but now my linux installation is
behaving like the windows one. I honestly don't know what changed,
which I know doesn't help people
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
>
> lc_collate is C, as are all the other lc settings.
>
> I have run the analyze commands.
>
> Still the same.
That is strange. I figured it had to be related to the locale and the LIKE
operator
simon godden wrote:
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.
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.
--
Simon Godden
--
simon godden wrote:
I did that, e.g. initdb --locale=C, re-created all my data and have
exactly the same problem.
I have two indexes, one with no options, and one with the varchar
operator options.
So the situation now is:
If I do a like query it uses the index with the varchar options;
If I do
simon godden wrote:
If the index isn't used, then we have problem #3. I think this is what
you are actually seeing. Your locale is something other than "C" and PG
doesn't know how to use like with indexes. Read up on operator classes
or change your locale.
http://www.postgresql.org/docs/8.1/stati
simon godden wrote:
(Sending again because I forgot to reply to all)
On 10/4/06, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
You can increase the max shared memory size if you have root access. See
http://www.postgresql.org/docs/8.1/interactive/kernel-resources.html#SYSVIPC-PARAMETERS
Sc
On 10/4/06, Richard Huxton wrote:
Issue "set enable_seqscan=false" and then run your explain analyse. If
your query uses the index, what is the estimated cost? If the estimated
cost is larger than a seq-scan that would indicate your configuration
settings are badly out-of-range.
I did that an
(Sending again because I forgot to reply to all)
On 10/4/06, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
You can increase the max shared memory size if you have root access. See
http://www.postgresql.org/docs/8.1/interactive/kernel-resources.html#SYSVIPC-PARAMETERS
Scroll down for Linux-spec
simon godden wrote:
The only major difference between the hardware is that the windows
machine has 2gb RAM and a setting of 1 shared memory pages,
whereas the 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
11 matches
Mail list logo
