On Thu, Sep 25, 2014 at 3:17 PM, Peter Geoghegan <p...@heroku.com> wrote: >> To find out how much that optimization buys, you >> should use tuples with many variable-length columns (say, 50) >> preceding the text column you're sorting on. I won't be surprised if >> that turns out to be expensive enough to be worth worrying about, but >> I have not benchmarked it. > > Sorry, but I don't follow. I don't think the pertinent question is if > it's a noticeable cost. I think the pertinent question is if it's > worth it. Doing something about it necessitates a lot of extra memory > access. Not doing something about it hardly affects the amount of > memory access required, perhaps not at all.
I think you're mincing words. If you go back and fix datum1, you'll spend a bunch of effort doing that. If you don't, you'll pay a cost on every comparison to re-find the relevant column inside each tuple. You can compare those costs in a variety of cases, including the one I mentioned, where the latter cost will be relatively high. -- Robert Haas EnterpriseDB: 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
