Re: Bad query plan with high-cardinality column

Поиск
Список
Период
Сортировка
От Alexander Staubo
Тема Re: Bad query plan with high-cardinality column
Дата
Msg-id D0D7098559DD470B9C2DE753E74B83E4@gmail.com
обсуждение исходный текст
Ответ на Re: Bad query plan with high-cardinality column  (Kevin Grittner <kgrittn@ymail.com>)
Ответы Re: Bad query plan with high-cardinality column  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-performance
On Friday, February 22, 2013 at 21:47 , Kevin Grittner wrote:
> I suspect you would be better off without those two indexes, and
> instead having an index on (conversation_id, created_at). Not just
> for the query you show, but in general.


Indeed, that solved it, thanks!



> In my experience these problems come largely from the planner not
> knowing the cost of dealing with each tuple. I see a lot less of
> this if I raise cpu_tuple_cost to something in the 0.03 to 0.05
> range.


Is this something I can just frob a bit without worrying about it adversely impacting database performance across the
board,or should I be very careful and do lots of testing on a staging box first? 


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

Предыдущее
От: Alexander Staubo
Дата:
Сообщение: Re: Bad query plan with high-cardinality column
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Bad query plan with high-cardinality column