Jeff Davis <pg...@j-davis.com> writes: > The way I see it, there are two strategies: > (a) build up a list as you go, and check it later > (b) do a check of the full table at once
> The patch seems like a reasonable implementation of (a), so what it's > missing is the ability to fall back to (b) when the list gets too large > (compared with available memory or relative to the table size). > Are you suggesting that we wait until (b) is implemented, or do you > envision something else entirely? What's mainly bothering me is the fear that real use cases are so heavily skewed towards (b) that we shouldn't bother implementing (a) at all. In that case we'd end up throwing away a lot of this patch, or else carrying a lot of not-very-useful code. I don't have a lot of concrete evidence about this, but as I said most of the complaints we've heard are suggesting bulk updates, eg http://archives.postgresql.org/pgsql-bugs/2003-05/msg00052.php http://archives.postgresql.org/pgsql-bugs/2004-09/msg00248.php http://archives.postgresql.org/pgsql-bugs/2007-07/msg00070.php There are some suggesting the other, eg, http://archives.postgresql.org/pgsql-bugs/2008-01/msg00172.php but they're clearly in the minority. It's possible that the first group are just using simple updates to illustrate the bug, rather than as examples of what they really want to do, but I'm unconvinced of that. Anyway, I'd feel a lot better about it if there were a near-term plan to do something about (b). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
