Re: performance of IN (subquery)

Поиск
Список
Период
Сортировка
От Arthur Ward
Тема Re: performance of IN (subquery)
Дата
Msg-id 5457.24.98.133.164.1093572855.squirrel@alpha.dominionsciences.com
обсуждение исходный текст
Ответ на Re: performance of IN (subquery)  (Paul Tillotson <pntil@shentel.net>)
Ответы Re: performance of IN (subquery)  (Greg Stark <gsstark@mit.edu>)
Список pgsql-general
> Afterthought: It would be nice if the database was smart enough to
> analyze a table of its own accord when a sequential scan returns more
> than, say, 20 times what it was supposed to.

I've wondered on several occasions if there is any good reason for PG not
to automatically perform an analyze concurrently with a seq scan as it's
happening. That way, no extra disk IO is needed and the stats could say
up-to-date for almost free.

Any hackers around who can say why this might be a bad idea, or is it one
of those things that just needs a volunteer? (I'm not; at least not now.)

В списке pgsql-general по дате отправления:

Предыдущее
От: CSN
Дата:
Сообщение: Re: owner orphaned databases
Следующее
От: Joel
Дата:
Сообщение: Re: UTF-8 and LIKE vs =