From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Karl Denninger" <karl(at)denninger(dot)net> |
Cc: | <pgsql-performance(at)postgresql(dot)org>,<pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: SQL Query Performance - what gives? |
Date: | 2009-08-18 21:59:22 |
Message-ID: | 4A8ADDEA0200002500029CA3@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance pgsql-sql |
Karl Denninger <karl(at)denninger(dot)net> wrote:
> -> Index Scan using forum_name on forum
> (cost=0.00..250.63 rows=1 width=271) (actual time=0.013..0.408
> rows=63 loops=1)
> Filter: (((contrib IS NULL) OR (contrib = '
> '::text) OR (contrib ~~ '%b%'::text)) AND ((permission & 127) =
> permission))
The biggest issue, as far as I can see, is that it thinks that the
selection criteria on forum will limit to one row, while it really
matches 63 rows.
You might be able to coerce it into a faster plan with something like
this (untested):
select *
from (select * from post
where invisible <> 1
and to_tsvector('english', message)
@@ to_tsquery('violence')
) p,
forum
where forum.name = p.forum
and (permission & '127') = permission
and (contrib is null or contrib = ' ' or contrib like '%b%')
order by modified desc
limit 100
;
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Slava Moudry | 2009-08-18 22:11:20 | Re: number of rows estimation for bit-AND operation |
Previous Message | Scott Marlowe | 2009-08-18 21:58:29 | Re: number of rows estimation for bit-AND operation |
From | Date | Subject | |
---|---|---|---|
Next Message | Karl Denninger | 2009-08-18 23:03:44 | Re: SQL Query Performance - what gives? |
Previous Message | drew | 2009-08-18 21:02:02 | Updating one table with data from another |