Re: [GENERAL] OUTER JOIN IS SLOW
| От | Benjamin Arai |
|---|---|
| Тема | Re: [GENERAL] OUTER JOIN IS SLOW |
| Дата | |
| Msg-id | 458DE6DB.2060609@araisoft.com обсуждение исходный текст |
| Ответ на | Re: [GENERAL] OUTER JOIN IS SLOW (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-admin |
Hi, I did a vacuum with -z and it fixed the issue. I was not aware that vacuumdb didn't ANALYZE by default. Thanks everybody for all of the help! Benjamin Tom Lane wrote: > Benjamin Arai <benjamin@araisoft.com> writes: > >> -> Index Scan using mutualfd_weekday_qbid_pkey_idx on >> mutualfd_weekday_qbid (cost=0.00..6.01 rows=1 width=19) (actual >> time=34.579..8510.801 rows=253 loops=1) >> Index Cond: ((pkey >= '2005-12-15'::date) AND (pkey <= >> '2006-12-15'::date)) >> Filter: (cusip = '92193920'::text) >> > > Hm, so how many rows in mutualfd_weekday_qbid for that date? > And how many satisfy the cusip condition? (I suppose 253, > but it looks like that must be a very small fraction of all > the rows for that date.) > > The selectivity estimators are not great about dealing with > zero-width intervals like this one (in fact, if you look at the > code you'll find it doesn't even bother to distinguish '>' from '>=' > ... something we should probably try to improve sometime). > > You'd probably have better luck if you could fold the WHERE condition > down to "pkey = '2005-12-15'". Dunno how feasible that is for your > application. > > regards, tom lane > >
В списке pgsql-admin по дате отправления: