Jay Levitt <jay.levitt@xxxxxxxxx> writes: > So you can see where I'm going. I know if I break everything into > elegant, composable functions, it'll continue to perform poorly. If I > write one big hairy, it'll perform great but it will be difficult to > maintain, and it will be inelegant and a kitten will die. My tools > are CTEs, subqueries, aliases, SQL functions, PL/pgSQL functions, and > views (and other tools?) What optimizations do each of those prevent? plpgsql functions are black boxes to the optimizer. If you can express your functions as single SQL commands, using SQL-language functions is usually a better bet than plpgsql. CTEs are also treated as optimization fences; this is not so much an optimizer limitation as to keep the semantics sane when the CTE contains a writable query. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
