Re: Yet another abort-early plan disaster on 9.3

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Yet another abort-early plan disaster on 9.3
Дата
Msg-id CA+U5nMJHnyoNicXL0em_qF5HNQG8MjwFtFNzf+fB5x3bqCM=fg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Yet another abort-early plan disaster on 9.3  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-performance
On 29 September 2014 22:54, Josh Berkus <josh@agliodbs.com> wrote:
> On 09/26/2014 01:06 AM, Simon Riggs wrote:
>> On 23 September 2014 00:56, Josh Berkus <josh@agliodbs.com> wrote:
>>
>>> We've hashed that out a bit, but frankly I think it's much more
>>> profitable to pursue fixing the actual problem than providing a
>>> workaround like "risk", such as:
>>>
>>> a) fixing n_distinct estimation
>>> b) estimating stacked quals using better math (i.e. not assuming total
>>> randomness)
>>> c) developing some kind of correlation stats
>>>
>>> Otherwise we would be just providing users with another knob there's no
>>> rational way to set.
>>
>> I believe this is a serious issue for PostgreSQL users and one that
>> needs to be addressed.
>>
>> n_distinct can be fixed manually, so that is less of an issue.
>
> It's an issue for the 99.8% of our users who don't know what n_distinct
> is, let alone how to calculate it.  Also, changing it requires an
> exclusive lock on the table. Of course, you and I have been over this
> issue before.

In 9.4 you'll be able to set n_distinct using only a Share Update
Exclusive lock.

So that's no longer a problem.

The quality of the n_distinct itself is an issue, but with no current
solution, but then that is why you can set it manually,

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Yet another abort-early plan disaster on 9.3
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Yet another abort-early plan disaster on 9.3