uher dslij 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
Sorry for the premature send on that last email. Here is the full one:
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:
create function parentContainers(numeric) returns setof numeric
as '
se
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
uher dslij 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 ar
As a follow up to this issue on Graeme's suggestion in a private email,
I checked the statistics in both databases, and they were the same (these
values as seen from pg_stat_user_tables to not seem to propagate to slave
databases however). I even ran a manual analyze on the master database in
the
Hi,
We recently upgraded from pg 9.0.5 to 9.3.2 and we are observing much
higher load on our hot standbys (we have 3). As you can see from the query
plans below, we have some queries that are running 4-5 times slower now,
many due to what looks like a bad plan in 9.3. Are there any known issues
