Re: Query optimizer 8.0.1 (and 8.0)
От | pgsql@mohawksoft.com |
---|---|
Тема | Re: Query optimizer 8.0.1 (and 8.0) |
Дата | |
Msg-id | 16508.24.91.171.78.1108962922.squirrel@mail.mohawksoft.com обсуждение исходный текст |
Ответ на | Re: Query optimizer 8.0.1 (and 8.0) (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Query optimizer 8.0.1 (and 8.0)
|
Список | pgsql-hackers |
> Jim C. Nasby wrote: >> On Mon, Feb 14, 2005 at 09:55:38AM -0800, Ron Mayer wrote: >> >> > I still suspect that the correct way to do it would not be >> > to use the single "correlation", but 2 stats - one for estimating >> > how sequential/random accesses would be; and one for estimating >> > the number of pages that would be hit. I think the existing >> > correlation does well for the first estimate; but for many data >> > sets, poorly for the second type. >> >> Should this be made a TODO? Is there some way we can estimate how much >> this would help without actually building it? > > I guess I am confused how we would actually do that or if it is > possible. Bruce, we didn't get much time to talk at Linux world (It was nice to meet you). I'm not sure how you would go about it, but in my post "One big trend .." (In don't even remember anymore), I talk about tables that are physically sorted on multiple keys, the addresses: streetname, typename, state, zip. maple, st, ma, 02186 maple, st, ma, 02186 maple, rd, ma, 02186 maple, ave, ma, 02186 maple, st, me, ?????? Assuming the table is physically sorted by state, town (zip), streetname, streettype, zip. If one were to type: select * from locations where streetname = 'maple'; The analysis of that query improperly minimizes the correlation of the street address of the table at whole.
В списке pgsql-hackers по дате отправления: