That solved it.
Thanks!
Michael
- Original Message
From: Tom Lane
To: Michael Fork
Cc: pgsql-general@postgresql.org
Sent: Tue, December 29, 2009 11:19:42 PM
Subject: Re: [GENERAL] Planner Row Estimate with Function
Michael Fork writes:
>> Also, what happened to the type=&
Michael Fork writes:
>> Also, what happened to the type='CREDIT' condition in your query? Is
>> that a partial index?
> Yes, this is partial index. I should have included the index definition
> earlier:
Ah. The optimizer is ignoring the index stats on the grounds that
they are not representa
0'::text = ANY
(parsecardidfromreferencecode(reference_code)))
-> Bitmap Index Scan on idx_event_card_id (cost=0.00..1668821.37
rows=44565021 width=0)
Thanks.
Michael
- Original Message
From: Pavel Stehule
To: Michael Fork
Cc: pgsql-general@postgresql.org
Sent: Tue, December 2
l Fork
Cc: pgsql-general@postgresql.org
Sent: Tue, December 29, 2009 3:43:06 PM
Subject: Re: [GENERAL] Planner Row Estimate with Function
Michael Fork writes:
> I have an index scan on a custom function that is returning a wildly
> incorrect row estimate that is throwing off the rest of th
Michael Fork writes:
> I have an index scan on a custom function that is returning a wildly
> incorrect row estimate that is throwing off the rest of the query planning.
> The result of the function is roughly unique - there are a handful with
> multiple entries - but the planner is estimating
Michael Fork wrote on 29.12.2009 18:08:
I have an index scan on a custom function that is returning a wildly
incorrect row estimate that is throwing off the rest of the query
planning. The result of the function is roughly unique - there are a
handful with multiple entries - but the planner is e
0 width=103)
> Index Cond: ("substring"(reference_code, 3, 13) = '057729970'::text)
> (2 rows)
> Thanks.
>
>
> Michael
>
>
>
> - Original Message
> From: Pavel Stehule
> To: Michael Fork
> Cc: pgsql-general@postgresql.org
> Se
18:52 PM
Subject: Re: [GENERAL] Planner Row Estimate with Function
Hello
2009/12/29 Michael Fork :
> I have an index scan on a custom function that is returning a wildly
> incorrect row estimate that is throwing off the rest of the query planning.
> The result of the function is roughly
Hello
2009/12/29 Michael Fork :
> I have an index scan on a custom function that is returning a wildly
> incorrect row estimate that is throwing off the rest of the query planning.
> The result of the function is roughly unique - there are a handful with
> multiple entries - but the planner is
I have an index scan on a custom function that is returning a wildly incorrect
row estimate that is throwing off the rest of the query planning. The result
of the function is roughly unique - there are a handful with multiple entries -
but the planner is estimating 227,745 rows. I re-ran ANALY
10 matches
Mail list logo
