>> I agree that the FSM behaviour shouldn't be linked to index existence.
>> IMHO that should be a separate table parameter, WITH (fsm_mode = append)
>> Index only scans would also benefit from that.
>
> -1 ... I cannot believe that such a parameter would ever get turned on
> in production by anyone. If your table has a significant update rate,
> the resulting table bloat would make such behavior completely
> infeasible. If you have few enough updates to make such a behavior
> practical, then you can live with the expensive index updates instead.
I'm also thinking that if a table is really append-only, then there are
never any middle-of-the-table pages in the FSM, no?
Where this falls down is the table which is
mostly-append-but-occasionally-needs-an-update-or-delete. I think the
answer there is to look for a way to make updating the index block range
faster, not ways to modify how we append to the heap. If we told users
"tables with Minmax indexes will be very expensive to update" then I
think they'd live with it; dropping and readding an index to enable fast
updates is something which is already familiar.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
