Re: Performance regressions in PG 9.3 vs PG 9.0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: uher dslij <codon3(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance regressions in PG 9.3 vs PG 9.0
Date: 2014-04-09 01:39:40
Message-ID: 1309.1397007580@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

uher dslij <codon3(at)gmail(dot)com> writes:
> Thanks for your reply Tom. I've found that the culprit is the function
> parentContainers(), which recurses up a folder structure and looks like
> this:

Hmm ... I had noticed the execution of that in a subplan, but it appeared
that the subplan was being done the same number of times and took about
the same amount of time in both 9.0 and 9.3, so I'd discounted it as the
source of trouble. Still, it's hard to argue with experimental evidence.

> 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;

Yeah, that looks like performance trouble waiting to happen --- it's not
clear what would bound the recursion, for one thing. Have you considered
replacing this with a RECURSIVE UNION construct? Wasn't there in 9.0
of course, but 9.3 can do that.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2014-04-09 11:46:27 Re: Why shared_buffers max is 8GB?
Previous Message 'Andrew W. Gibbs' 2014-04-09 00:57:18 Re: query against large table not using sensible index to find very small amount of data