On Wed, Nov 2, 2016 at 4:09 PM, Adam Brusselback <adambrusselb...@gmail.com> wrote: >> There may be some situations where crawling the indexes a row at a >> time will perform better than this by enough to want to retain that >> option. > > If an index existed, wouldn't it still be able to use that in the set-based > implementation?
Yes. The optimizer would compare plans and pick the lowest cost. > Is there something which would make doing the check > set-based ever worse than row based inherently? I'm not sure. I doubt that it would ever lose by very much, but only benchmarking can really answer that question. Anyway, it's probably premature to get too far into it now. It just occurred to me that it might be a worthwhile project once the transition tables are available, so I did a quick set of triggers to see what the potential was in a "best case" scenario. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
