On Tue, 6 Jul 2004, Chris Smith wrote:
> Stephan Szabo wrote:
>
> > I wonder if in practice this query uses distinct to get around a
> > problem with subqueries.
>
> Yes, it does exactly that. The database was recently moved over to PostgreSQL
> 7.4. The thought of switching over to IN-subqueries is a bit scary, since the
> query generator is a really over-generalized mess of about 7000 LOC in 17
> different source files; but I'll certainly look at that.
It might be worth just converting some by hand to see what explain analyze
says about them in contrast to the original.
> > These steps are for the distinct. It's not alot of actual time, but
> > if the row set returned was large enough to exceed sort_mem the sort
> > might start going off to disk and be slower.
>
> Indeed, that looks like it could be a problem for some of our larger customers
> who have up to tens of thousands of users. The IN form would avoid this sort?
The IN form would potentially use a generally different plan. It still
uses sort_mem for some of its determinations, but I *think* you'd get more
in than you would be for the sort. If you have the RAM and are doing
queries like this alot, you might want to raise sort_mem if you haven't
changed it from the default.
> > The row estimate is pretty reasonable, estimated 629 versus actual
> > 753. How many rows are in useraccount? I'm wondering if 629 is a
> > reasonable percentage of the rows to see if seq scan is reasonable
> > here.
>
> Total? On this server, it's currently 2566.
Okay, so 629 doing a seq scan is pretty reasonable if the table doesn't
have alot of empty space.
> > Here the estimate isn't so good, estimated 115 vs actual 1328. You
> > might want to consider raising the groupid column's statistics target
> > and re-analyzing to see if you can get a better estimate.
>
> Alright. So how exactly do I raise the groupid column's statistics target?
Oops, I mentioned it in a previous version of that paragraph and
apparently removed it upon editing.
ALTER TABLE <table> ALTER COLUMN <column> SET STATISTICS <integer>.
Maybe try 100 to see what it gives you.
