>> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers