Steven Schlansker-3 wrote > The code may get changed multiple times in the same day, if I am > busy hacking on it. On the production table??? The other thought-line is just use a (primary key, version) index and make use LIMIT / OFFSET with an ORDER BY on the PK and the filter on version AFTER the initial rows are selected. UPDATE tbl SET .... FROM ( WITH possible_set AS ( SELECT pkid, version FROM tbl ORDER BY pkid DESC LIMIT 5000 OFFSET 10000 ) SELECT pkid FROM possible_set WHERE version <> 'CURRENT_VERSION' ) src tbl.pkid = src.pkid ; DESC pkid means that newer records are prioritized over older ones. Probably want a table to keep track of which ranges have already been reserved and/or updated then client can connect and reserve a range and perform an update. Concurrency and failure modes would need attention. You can also keep track on entire ranges and identify which version all the records are at and select ranges based upon how far behind the current version they are (or whatever priority algorithm you desire - including manual tweaks). David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Index-over-only-uncommon-values-in-table-tp5759735p5759765.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
