From: | Brad Hilton <bhilton(at)vpop(dot)net> |
---|---|
To: | jasiek(at)serwer(dot)skawsoft(dot)com(dot)pl |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: sub-query optimization |
Date: | 2003-02-14 19:42:27 |
Message-ID: | 1045251747.29974.45.camel@aragorn.vpop.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Fri, 2003-02-14 at 11:21, jasiek(at)serwer(dot)skawsoft(dot)com(dot)pl wrote:
> Can you test these two queries?
Thanks, I'll test them shortly. I wanted to answer your other
questions, first:
> Can you say anything about data statistics in your tables? How
> many rows are with category_id=null?
>
> I looked into query definition once again. Your query doesn't make
> sense - article_categories have not null category_id... What do you really
> want to do?
Sorry to cause confusion. My original query and db format were fairly
complex so I didn't want to distract from my problem. My actual query
looks like:
select * from articles where exists
(select 1 from article_categories, categories, category_map
where
article_categories.article_id = articles.id and
categories.restrict_views = FALSE and
article_categories.category_id = categories.id and
category_map.parent_id = 1 and
category_map.child_id = categories.id and
category_map.child_id = article_categories.category_id and
articles.post_status = 'publish'
)
and
post_status = 'publish'
------------------
The problem is that sometimes there are no categories with
"restrict_views = FALSE" and the query takes a *long* time: 23 seconds.
However, if I simply add the 'articles' table to the inner query it
takes 0.23 msec.
*But*, sometimes there are many categories where "restrict_views =
FALSE", and in such a case adding the 'articles' table to the inner
query actually hurts performance quite a bit.
Does that help at all?
Thanks,
-Brad
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2003-02-14 20:04:45 | Re: sub-query optimization |
Previous Message | Johannes Lochmann | 2003-02-14 19:31:31 | Re: PL/PGSQL EDITOR |