On Mon, Nov 3, 2014 at 10:18 AM, Greg Stark <st...@mit.edu> wrote: > On Sat, Nov 1, 2014 at 9:09 PM, Robert Haas <robertmh...@gmail.com> wrote: >> 1. Any non-trivial piece of PostgreSQL code is likely to contain >> syscache lookups. >> 2. Syscache lookups had better work in parallel workers, or they'll be >> all but useless. > > I've been using parallel sorts and index builds in my mental model of > how this will be used. I note that sorts go out of their way to look > up all the syscache entries in advance precisely so that tuplesort > doesn't start doing catalog lookups in the middle of the sort.
This isn't really true. Routines like varstr_cmp() do syscache lookups and de-TOASTing. We've recently tried to reduce that with the sortsupport stuff, but it hasn't eliminated it completely, and there are other cases. This is really the key point that I think everybody needs to understand: a lot of code that you think doesn't do anything complicated actually reads from the database - generally either in the form of syscache lookups, or in the form of de-TOASTing. Most of that code doesn't perform those operations *frequently*, but that's because there are backend-private caches that minimize the number of times we actually hit the database. But restructuring all of that code to do no database access whatsoever would be a very difficult proposition and would involve painful sacrifices, which is, I imagine, why it is the way it is. -- 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
