From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Inefficiency in InitIndexFreeSpaceMap |
Date: | 2008-11-06 13:59:12 |
Message-ID: | 17055.1225979952@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> Why is InitIndexFreeSpaceMap coded to test for the FSM file already
>> existing? AFAICS it cannot yet exist and it should be an error anyway
>> if it does.
> Hmm. The FSM file can exist, if the index isn't created anew, but
> truncated and rebuilt. However, we normally create a new relfilenode in
> that case, so the only place where that actually happens is with a
> temporary ON COMMIT DELETE ROWS table.
Hm. I would say that the brokenness in RelationTruncateIndexes is that
it truncates the main fork and not the others. This is unlike other
places that do such things.
>> The smgrexists probe is hardly free, so losing it would be
>> good.
> Well, it's only done in index build, so I'm not too worried.
See Kevin Grittner's gripe about the speed of temp table creation.
I'm already worried that the FSM changes will have a huge negative
impact on that. Adding extra filesystem operations that don't have
to be there doesn't help.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-11-06 14:01:01 | Timing problem in DROP TABLESPACE? |
Previous Message | Tom Lane | 2008-11-06 13:52:01 | Re: [WIP] In-place upgrade |