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)  (Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Design notes for BufMgrLock rewrite
Следующее
От: "Sergey E. Koposov"
Дата:
Сообщение: Re: Strange RETURN NEXT behaviour in Postgres 8.0