Re: Performance regressions in PG 9.3 vs PG 9.0
| От | uher dslij |
|---|---|
| Тема | Re: Performance regressions in PG 9.3 vs PG 9.0 |
| Дата | |
| Msg-id | CAKGDDes8qwGvwVKUxY0Kt=QAHixXXaJ2ttsw9AmXMqySTEOGrg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Performance regressions in PG 9.3 vs PG 9.0 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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@sss.pgh.pa.us> wrote:
uher dslij <codon3@gmail.com> writes:I don't see any reason to think this is a planner regression. The
> 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?
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
В списке pgsql-performance по дате отправления: