On Sat, Feb 5, 2011 at 3:05 AM, Noah Misch <noah@leadboat.com> wrote:
> Correct. It's perhaps obvious, but rewriting the table will always reindex it.
Right.
>> 3. If we're changing the data type of a column in the table, reindex the table.
>
> Rebuild indexes that depend on a changing column. Other indexes can stay.
Good point.
>> 4. If we're changing tablespaces, copy the table block-by-block.
>>
>> I might be missing something, but I don't see that the patch includes
>> step #3, which I think is necessary. For example, citext is binary
>> coercible to text, but you can't reuse the index because the
>> comparison function is different. Of course, if you're changing the
>> type of a column to its already-current type, you can skip #3, but if
>> that's the only case we can optimize, it's not much of an
>> accomplishment. I guess this gets back to the ALTER TYPE 7 patch,
>> which I haven't looked at in detail, but I have a feeling it may be
>> controversial.
>
> It's there, but it's happening rather implicitly.
I see now. So you're actually not really making any change to that
machinery. It's sufficient to just skip the rewrite of the heap when
it isn't needed, and without any particular code change the indexes
will sort themselves out.
> We have no such optimization during #1, either, so #2+#3 is never worse. In
> particular, #1 scans the table (# indexes total) + 1 times, while #2+#3 scans it
> (# of indexes depending on changed columns) + 1 times.
OK.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company