On 29 September 2014 22:54, Josh Berkus <josh@xxxxxxxxxxxx> wrote: > On 09/26/2014 01:06 AM, Simon Riggs wrote: >> On 23 September 2014 00:56, Josh Berkus <josh@xxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
