Jessi Berkelhammer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> For some reason it's estimating only one row out of the
>> clinical_reg_current view will satisfy the
>> tier_program(benefit_type_code) = 'SAGE' constraint.
My math was off the other day --- actually, that's exactly what you'd
ex
Hello.
Thanks for the help.
Tom Lane wrote:
Jessi Berkelhammer <[EMAIL PROTECTED]> writes:
Here are the 3 EXPLAIN ANALYZE commands followed by the output:
Well, here's the problem:
Join Filter: (clinical_reg_current.client_id = client.client_id)
-> Subquery Scan clinic
Jessi Berkelhammer <[EMAIL PROTECTED]> writes:
> Here are the 3 EXPLAIN ANALYZE commands followed by the output:
Well, here's the problem:
> Join Filter: (clinical_reg_current.client_id = client.client_id)
> -> Subquery Scan clinical_reg_current (cost=754.36..758.23
> rows=
Hello.
Thanks for the replies.
Pavel Stehule wrote:
> what do you do in x_program function? Are you sure so it is fast?
>
I do not think the function is the problem, as running the slow query
without it is just as slow, and similar queries using that function are
quick.
Tom Lane wrote:
Let
On 11/01/2008, Jessi Berkelhammer <[EMAIL PROTECTED]> wrote:
> Hello.
>
> I'm trying to figure out why a query I'm doing is incredibly slow (~10
> minutes.) The incredibly slow query is something like:
>
> SELECT count(*) from registration LEFT JOIN person USING (person_id)
> WHERE x_program(regist
Jessi Berkelhammer <[EMAIL PROTECTED]> writes:
> The hold-up seems to be in a 'Nested Loop Left Join', which is only in
> the plan for the slow query.
> Here are the first two lines of EXPLAIN ANALYZE on the slow query:
So you've left out all the information that would let anyone guess what
the p
Hello.
I'm trying to figure out why a query I'm doing is incredibly slow (~10
minutes.) The incredibly slow query is something like:
SELECT count(*) from registration LEFT JOIN person USING (person_id)
WHERE x_program(registration.x_type_code) = 'blah';
The person view is quite big (~69000
