Re: Performance regressions in PG 9.3 vs PG 9.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for your reply Tom.  I've found that the culprit is the function parentContainers(), which recurses in a folder structure and looks like this:

create function parentContainers(numeric) returns setof numeric
as '
    select parentContainers( (select container_id from container where id = $1 ) )
union
select id from container where id = $1
        ' language sql stable returns null on null input;


Is is declared stable, but I know that is just planner hint, so it doesn't guarantee that it will only get called once.  If I replace the function call with the two values this function returns, 


On Tue, Apr 8, 2014 at 5:26 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
uher dslij <codon3@xxxxxxxxx> writes:
> The EXPLAINs all pretty much look like my original post.  The planner in
> 9.2 and above is simply not using bitmap heap scans or bitmap index scans?
>  What could be the reason for this?

I don't see any reason to think this is a planner regression.  The
rowcount estimates are pretty far off in both versions; so it's just a
matter of luck that 9.0 is choosing a better join order than 9.3.

I'd try cranking up the statistics targets for the join columns
(particularly domain_id) and see if that leads to better estimates.

                        regards, tom lane


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux