| От | Tom Lane |
|---|---|
| Тема | Re: Hash or merge join instead of inner loop |
| Дата | |
| Msg-id | 4799.1055278605@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Hash or merge join instead of inner loop ("Jim C. Nasby" <jim@nasby.net>) |
| Список | pgsql-performance |
"Jim C. Nasby" <jim@nasby.net> writes:
> On Tue, Jun 10, 2003 at 02:15:11AM -0400, Tom Lane wrote:
>> ... In reality, most of the upper btree levels will no doubt
>> stay in memory during such a query, and so this estimate charges many
>> more reads than really occur. Fixing this is on the todo list, but no
>> one's got to it yet. (It's not clear to me how to put the consideration
>> into the planner's cost algorithms in a clean way.)
> What about just ignoring all but the leaf pages?
IIRC, we already know what cost model we want to use. The problem is
that the planner's code structure makes it difficult for the indexscan
coster to know that the indexscan will be applied repeatedly rather than
just once. That's what has to be solved.
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера