On Mon, Nov 3, 2014 at 10:18 AM, Greg Stark <stark@mit.edu> wrote:
> On Sat, Nov 1, 2014 at 9:09 PM, Robert Haas <robertmhaas@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
