Re: planner or statistical bug on 8.5

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Matteo Beccati <php(at)beccati(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: planner or statistical bug on 8.5
Date: 2010-01-12 18:21:48
Message-ID: 21518.1263320508@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Tom made some changes for 8.5 that will result in materialization
> being used in more places, and I think we're seeing that here. The
> planner thinks that materializing the inner side of the nestloop will
> save it from going to disk for every iteration, but that's not really
> true. b will be fully cached anyway, but the planner doesn't know
> that. I think we need to think about this a little more before we let
> this code out into the wild, or we'll get complaints about materialize
> nodes being inserted in places where they only slow things down...

I don't think it's a big deal. The materialize node won't create much
of any slowdown unless its tuplestore gets big enough to spill to disk.
And at that point you're probably talking enough savings from avoided
visibility checks to make it worthwhile.

It's possible that the cost parameters in there need some fine-tuning,
but I don't think the costing model per se is wrong. It's certainly
far less bogus than it was before.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-12 18:27:33 Re: NOT NULL violation and error-message
Previous Message Robert Haas 2010-01-12 18:13:40 Re: planner or statistical bug on 8.5