"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
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
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
>
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'
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
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
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
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
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
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
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
11 matches
Mail list logo