simon@2ndQuadrant.com (Simon Riggs) writes:
> On Tue, 2010-03-16 at 15:29 +0000, Greg Stark wrote:
>
>> big batch delete
>
> Is one of the reasons for partitioning, allowing the use of truncate.
Sure, but it would be even nicer if DELETE could be thus made cheaper
without needing to interfere with the schema.
The concurrency issue might be resolved (*might!*) by the following
complication...
- A delete request is looking at a page, and concludes, "oh, all the tuples here are now marked dead!".
- It flags the page as *possibly* dead. Almost what Greg suggests for the visibility map, but this is just marking it
as"proposed dead."
- It throws the page number, along with xid, into a side map.
When something wants to do something with the page (e.g. - vacuum), it
sees that it's "possibly dead," and looks at the "side map" for the list
of xids that wanted to mark the page dead.
for each xid: if xid is still active do nothing with it else remove xid entry from the map
if all xids were failed remove flag from page
if any xid committed empty the page; the tuples are all dead
I'm less confident about that last "clause" - I *think* that if *any*
page-clearing XID is found, that means the page is well and truly clear,
doesn't it?
The extra "map" mayn't be a nice thing.
It's food for thought, anyways.
--
let name="cbbrowne" and tld="linuxfinances.info" in String.concat "@" [name;tld];;
The real problem with the the year 2000 is that there are too many
zero bits and that adversely affects the global bit density.
-- Boyd Roberts <boyd@france3.fr>