| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: [PATCHES] Minimum selectivity estimate for LIKE 'prefix%' |
| Date: | 2008-03-31 10:02:47 |
| Message-ID: | 200803311202.47718.peter_e@gmx.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Am Donnerstag, 6. März 2008 schrieb Tom Lane:
> What I propose doing about this is a small variant on Peter's original
> suggestion: compute the estimated selectivity for
> col = 'prefix'
> and clamp the result of prefix_selectivity to be at least that.
OK, first results with this patch are in: The selectivity estimations are
adjusted nicely, but the cost calculation doesn't change at all. Before:
Index Scan using foo_idx_3 on foo foo (cost=0.01..6.03 rows=1 width=8)
After:
Index Scan using foo_idx_3 on foo foo (cost=0.01..6.03 rows=627 width=8)
How is that possible?
Btw., the corresponding query plan for the LIKE 'constant' case is:
Index Scan using foo_idx_3 on foo foo (cost=0.00..2527.84 rows=627 width=8)
This is what we had hoped to get in the "after" case.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2008-03-31 12:34:26 | Re: ANALYZE getting dead tuple count hopelessly wrong |
| Previous Message | ohp | 2008-03-31 10:01:13 | Re: jaguar is failing |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-03-31 10:52:29 | Re: Consistent \d commands in psql |
| Previous Message | NikhilS | 2008-03-31 08:36:16 | Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited] |