From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: query very slow when enable_seqscan=on |
Date: | 2006-07-03 23:05:46 |
Message-ID: | 7353.1151967946@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-performance |
Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl> writes:
> I have a very slow query when enable_seqscan=on and very fast when
> enable_seqscan=off.
Here's your problem:
> -> Seq Scan on organization (cost=0.00..480.95 rows=1 width=4) (actual time=0.071..69.702 rows=1892 loops=1)
> Filter: ((organization_location)::text ~* 'warszawa'::text)
If it were estimating something like the actual number of rows matching
that filter, it'd never have chosen a nestloop plan like that.
How many rows are there in the organization table?
This is probably the fault of the pattern-selectivity heuristic: it's
far too optimistic about long match strings eliminating a lot of rows.
I think there's been some discussion of modifying that logic but no
one's really stepped up with a better idea.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomasz Ostrowski | 2006-07-04 08:37:33 | Re: query very slow when enable_seqscan=on |
Previous Message | Simon Riggs | 2006-07-03 23:05:42 | Re: query very slow when enable_seqscan=on |
From | Date | Subject | |
---|---|---|---|
Next Message | Guoping Zhang | 2006-07-04 04:35:37 | Re: Is postgresql ca do the job for software deployed in ASP ou SaaS mode? |
Previous Message | Simon Riggs | 2006-07-03 23:05:42 | Re: query very slow when enable_seqscan=on |