On Thu, May 8, 2014 at 3:10 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Simon Riggs (si...@2ndquadrant.com) wrote: >> It would seem normal and natural to have >> >> * pg_joinam catalog table for "join methods" with a join method API >> Which would include some way of defining which operators/datatypes we >> consider this for, so if PostGIS people come up with some fancy GIS >> join thing, we don't invoke it every time even when its inapplicable. >> I would prefer it if PostgreSQL also had some way to control when the >> joinam was called, possibly with some kind of table_size_threshold on >> the AM tuple, which could be set to >=0 to control when this was even >> considered. > > It seems useful to think about how we would redefine our existing join > methods using such a structure. While thinking about that, it seems > like we would worry more about what the operators provide rather than > the specific operators themselves (ala hashing / HashJoin) and I'm not > sure we really care about the data types directly- just about the > operations which we can do on them..
I'm pretty skeptical about this whole line of inquiry. We've only got three kinds of joins, and each one of them has quite a bit of bespoke logic, and all of this code is pretty performance-sensitive on large join nests. If there's a way to make this work for KaiGai's use case at all, I suspect something really lightweight like a hook, which should have negligible impact on other workloads, is a better fit than something involving system catalog access. But I might be wrong. I also think that there are really two separate problems here: getting the executor to call a custom scan node when it shows up in the plan tree; and figuring out how to get it into the plan tree in the first place. I'm not sure we've properly separated those problems, and I'm not sure into which category the issues that sunk KaiGai's 9.4 patch fell. Most of this discussion seems like it's about the latter problem, but we need to solve both. For my money, we'd be better off getting some kind of basic custom scan node functionality committed first, even if the cases where you can actually inject them into real plans are highly restricted. Then, we could later work on adding more ways to inject them in more places. -- 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
