From: | uher dslij <codon3(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance regressions in PG 9.3 vs PG 9.0 |
Date: | 2014-04-09 00:16:30 |
Message-ID: | CAKGDDes8qwGvwVKUxY0Kt=QAHixXXaJ2ttsw9AmXMqySTEOGrg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> uher dslij <codon3(at)gmail(dot)com> 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
>
From | Date | Subject | |
---|---|---|---|
Next Message | uher dslij | 2014-04-09 00:23:21 | Re: Performance regressions in PG 9.3 vs PG 9.0 |
Previous Message | Jeff Janes | 2014-04-08 22:51:46 | Re: query against large table not using sensible index to find very small amount of data |