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 по дате отправления: