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