On Sat, Feb 5, 2011 at 3:05 AM, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
