Tom Lane <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: > > But on that note, is it ok to use the bulkdelete index AM methods for > > non-vacuum purposes > > Um, what would those be?
I'm sure with a little work I can imagine lots of reasons to want to pull out all the index tuples from an index other than vacuum. I can't actually name any right now, but I'm sure I'll think of some :) > ambulkdelete and amvacuumcleanup are most certainly not designed to be > used in any context other than VACUUM. You might be able to abuse them > for some other purpose, but don't expect a warranty. What I'm doing now is calling ambulkdelete with a callback that returns false for every tuple and stuffs the item pointer into a data structure. It seems to be working but I haven't tested it thoroughly yet. I'm worried that ambulkdelete might have side effects on the index that aren't obvious. Other than bumping the vacuum cycle id I don't see any in a quick scan of the btree code. But I could have missed something or other access methods could behave differently. I would be happier with a generic "index sequential scan" interface. I realize the cycle id trick restricts any such api to a single scanner at a time which is fine for my purposes. Actually is that really true? Wouldn't the cycle id setup work fine if a subsequent scan started and the cycle id was bumped a second time? If you find a page that was split with a cycle id greater than yours then you still know it was split after you started. As long as the cycle id doesn't wrap while a scan is proceeding it should be fine. Perhaps tagging the split pages with the xid of the most recent scan instead of a separate cycle id concept? -- greg ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly