Re: Partitioned Tables and ORDER BY

Поиск
Список
Период
Сортировка
От Grzegorz Jaśkiewicz
Тема Re: Partitioned Tables and ORDER BY
Дата
Msg-id 2f4958ff0910190913p26b908bardf117b824b0a0505@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Partitioned Tables and ORDER BY  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Partitioned Tables and ORDER BY
Список pgsql-performance


2009/10/19 Robert Haas <robertmhaas@gmail.com>
2009/10/19 Grzegorz Jaśkiewicz <gryzman@gmail.com>:
>
>
> On Sun, Oct 11, 2009 at 3:30 PM, Michal Szymanski <mich20061@gmail.com>
> wrote:
>>
>> We have similar problem and now we are try to find solution. When you
>> execute query on partion there is no sorting - DB use index to
>> retrieve data and if you need let say 50 rows it reads 50 rows using
>> index. But when you execute on parent table query optymizer do this:
>>
>>  ->  Sort  (cost=726844.88..748207.02 rows=8544855 width=37739)
>> (actual time=149864.868..149864.876 rows=50 loops=1)
>>
>> it means 8544855 rows should be sorted and it takes long minutes.
>
> The figures in first parenthesis are estimates, not the actual row count.
> If you think it is too low, increase statistic target for that column.

It's true that the figures in parentheses are estimates, it's usually
bad when the estimated and actual row counts are different by 5 orders
of magnitude, and that large of a difference is not usually fixed by
increasing the statistics target.

I thought that this means, that either analyze was running quite a long time ago, or that the value didn't made it to histogram. In the later case, that's mostly case when your statistic target is low, or that the value is really 'rare'.
 


--
GJ

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Partitioned Tables and ORDER BY
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Calculation of unused columns