Steven Schlansker-3 wrote > At some point, the code changes, and CURRENT_VERSION gets incremented. > Rows then slowly (over a period of days / weeks) get "upgraded" to the new > current version, in batches of thousands. > > This is what I mean by a very slowly changing mostly-constant value. This seems insane without knowing the details. This seems like it would be more of a cache invalidation problem. What percentage of your rows are being updated multiple times without ever being queried for other reasons? I was going to say that table partitioning (INHERITS) seems like a possibility; then I thought maybe not; now I'm back to suggesting you consider it. Every version of the extractor would get its own table. To "upgrade" you remove the record from the older table and add it to the newer one. Maybe even consider calling the these "version_upgraded" to distinguish them from records originally insert using the newest version. Or have "original version" as the partition key and a second "current version" field that varies. Not sure how the planner would be able to use constraint exclusion to limiting the scanning though... Hope this helps. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Index-over-only-uncommon-values-in-table-tp5759735p5759748.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
