Re: [GENERAL] not using index through procedure

2004-10-15 Thread Tom Lane
"Robin Ericsson" <[EMAIL PROTECTED]> writes: > Is there even a way to solve it this way via a procedure? If you want the range to depend on a procedure parameter then you're back to square one: the planner has no way to know the values that parameter will take on, and its default assumption is tha

Re: [GENERAL] not using index through procedure

2004-10-14 Thread Robin Ericsson
Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > One's marked VOLATILE, the other is marked IMMUTABLE. This affects > whether it's considered a constant, the planner estimates and hence > whether it uses the index. Is there even a way to solve it this way via a procedure? I've tried different

Re: [GENERAL] not using index through procedure

2004-10-14 Thread Martijn van Oosterhout
One's marked VOLATILE, the other is marked IMMUTABLE. This affects whether it's considered a constant, the planner estimates and hence whether it uses the index. On Thu, Oct 14, 2004 at 05:30:58PM +0200, Robin Ericsson wrote: > After some discussion on performance list, I guess this is back to a >

[GENERAL] not using index through procedure

2004-10-14 Thread Robin Ericsson
After some discussion on performance list, I guess this is back to a general question :) This is very simplified query of my real problem, but it should show the way of the problems. CREATE OR REPLACE FUNCTION ago(interval) RETURNS timestamp AS 'SELECT (now() - $1)::timestamp without time zone'

Re: [GENERAL] Not using index

2004-02-12 Thread Bas Scheffers
scott.marlowe said: > Yes. drop cpu_tuple_index_cost by a factor of 100 or so No effect. > Also up effective_cache_size. It's measured in 8k blocks, so for a That's better, set to 9000, which seems reasonable for my current setup, it will start using the index when RANDOM_PAGE_COST <= 1.5. > No

Re: [GENERAL] Not using index

2004-02-12 Thread scott.marlowe
On Thu, 12 Feb 2004, Bas Scheffers wrote: > Hi Scot, > > As "unrealistic" as it should be, I need <1 before Postgres takes the > bait. Initialy 0.7, to be exact, but later It also worked at a little > higher setting of 1. I have given PG 96Mb of memory to play with, so > likely all my data will b

Re: [GENERAL] Not using index

2004-02-12 Thread Bas Scheffers
Hi Scot, scott.marlowe said: > So, to start with, try changing random page cost. you can change it for As "unrealistic" as it should be, I need <1 before Postgres takes the bait. Initialy 0.7, to be exact, but later It also worked at a little higher setting of 1. I have given PG 96Mb of memory to

Re: [GENERAL] Not using index

2001-02-07 Thread Crispin Miller
Hi Tom, Jeorg, Thanks for the help - I thought I might be being a bit vague... Jeorg's suggestion solved my problem - I need to create an index across both columns: 'create index foo on bar ( baz, bang )' Like what Jeorg said I should :-) Appreciated, Crispin

Re: [GENERAL] Not using index

2001-02-07 Thread Joerg Hessdoerfer
At 14:47 07.02.01 +, you wrote: >Hi, >I have a table with about 8million tuples in it. I need to do a search >on two of the table's columns, so I've created a couple of indices, one >for each column. >Then I've run VACUUM ANALYZE. The query planner still wants to do a >sequential scan on the d

Re: [GENERAL] Not using index

2001-02-07 Thread Tom Lane
Crispin Miller <[EMAIL PROTECTED]> writes: > Then I've run VACUUM ANALYZE. The query planner still wants to do a > sequential scan on the database. Any idea where I'm going wrong? Not providing enough detail to let anyone help you ;-) Let's see the table schema (pg_dump -s -t table is a useful w

[GENERAL] Not using index

2001-02-07 Thread Crispin Miller
Hi, I have a table with about 8million tuples in it. I need to do a search on two of the table's columns, so I've created a couple of indices, one for each column. Then I've run VACUUM ANALYZE. The query planner still wants to do a sequential scan on the database. Any idea where I'm going wrong? C