2016-12-26 8:30 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > Hello Jim, > > If you want to ignore performance, there are things you can do with >> non-transactional variables that are simply not possible with tables. But >> even ignoring that, the performance cost of temp tables is massive compared >> to variables. >> > > Ok, then read "variables are like tables" instead of "variables are > tables". Note that I'm definitely interested in performance in the end, but > I'm first interested in discussing features. > > Currently I'm unconvinced by a proposal of variables that are in the > relation namespace (pg_class), are subject to GRANT/REVOKE, are managed > with CREATE/DROP *but* are somehow partly non transactional, and only alive > through sessions, and are only accessed through functions... > > My current thinking is that the proposed design is either too heavy > (pg_class, permissions) or too light (then why not possible persistence > and/or transactions?): I would be more at ease with very light-weight > typed? session variables stored in the server process "as is", without any > attempt at pg_class & permissions, or with more full featured variables, > but not something half-baked which seems designed for a particular use case > that I do not have. > > Not only is the access far more complex, but bloating is a major problem >> (both in the table itself as well as in the catalog). That's part of the >> driver for all the discussion about things like permanent temp tables >> (which still leaves a bloat and performance problem in the table itself). >> > > If a variable as currently discussed is in pg_class and subject to > permissions, then probably it will cost on the catalog side anyway, and at > least their existent would be transactional even if their value is not. >
the access right check has **constant** small cost (check in object cache). The proposed variables has not any negative effect on catalogue bloating because a metadata are persistent. It is reason why I use statement "CREATE VARIABLE", not "DECLARE VARIABLE" Regards Pavel > > -- > Fabien. >
