Re: changeset generation v5-01 - Patches & git tree

On 27 June 2013 23:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Exactly what is the argument that says performance of this
> function is sufficiently critical to justify adding both the maintenance
> overhead of a new pg_class index, *and* a broken-by-design syscache?
>

I think we all agree on changing the syscache.

I'm not clear why adding a new permanent index to pg_class is such a
problem. It's going to be a very thin index. I'm trying to imagine a use
case that has pg_class index maintenance as a major part of its workload
and I can't. An extra index on pg_attribute and I might agree with you. The
pg_class index would only be a noticeable % of catalog rows for very thin
temp tables, but would still even then be small; that isn't even necessary
work since we all agree that temp table overheads could and should be
optimised away somwhere. So blocking a new index because of that sounds
strange.

What issues do you foresee? How can we test them?

Or perhaps we should just add the index and see if we later discover a
measurable problem workload?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services