On 14/09/2010, at 10:37 AM, Yaroslav Tykhiy wrote:
On 14/09/2010, at 12:41 AM, Tom Lane wrote:
Yaroslav Tykhiy writes:
[...]
I think the major problem you're having is that the planner is
completely clueless about the selectivity of the condition
"substring"(v.headervalue, 0, 255)
Hi Tom,
On 14/09/2010, at 12:41 AM, Tom Lane wrote:
Yaroslav Tykhiy writes:
-> Bitmap Heap Scan on dbmail_headervalue v
(cost=1409.82..221813.70 rows=2805 width=16) (actual
time=28543.411..28623.623 rows=1 loops=1)
Recheck Cond: (v.headername_i
Yaroslav Tykhiy writes:
> -> Bitmap Heap Scan on dbmail_headervalue v
> (cost=1409.82..221813.70 rows=2805 width=16) (actual
> time=28543.411..28623.623 rows=1 loops=1)
> Recheck Cond: (v.headername_id = n.id)
> Fi
Hi Martin,
Thank you for your response!
On 13/09/2010, at 10:49 AM, Martin Gainty wrote:
a cursory look of the plan details a FTS on dbmail_headername
invoked by the JOIN clause
JOIN dbmail_headername n ON v.headername_id=n.id
you would accelerate the seek appreciably by placing indexes on b
a cursory look of the plan details a FTS on dbmail_headername invoked by the
JOIN clause
JOIN dbmail_headername n ON v.headername_id=n.id
you would accelerate the seek appreciably by placing indexes on both
participating columns
v.headername_id
n.id
I also see a FTS on domain_headervalue invoke
