Re: [HACKERS] WIP Patch: Precalculate stable functions,infrastructure v1
От | Marina Polyakova |
---|---|
Тема | Re: [HACKERS] WIP Patch: Precalculate stable functions,infrastructure v1 |
Дата | |
Msg-id | 9caa5cc6be9c41140915dcdf8e4847a6@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] WIP Patch: Precalculate stable functions,infrastructure v1 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] WIP Patch: Precalculate stable functions, infrastructure v1
|
Список | pgsql-hackers |
>> Like for the previous patches it seems that there is >> no obvious performance degradation too on regular queries (according >> to >> pgbench). > > pgbench probably isn't a very good test for this sort of thing - it > only issues very short-running queries where the cost of evaluating > expressions is a relatively small part of the total cost. Even if > things get worse, I'm not sure if you'd see it. If there's a mistake, for example, more than 1 try to replace cached expressions in the whole query tree, results of "in buffer test" or "mostly cache test" can different a little.. > I'm not sure exactly > how you could construct a test case that could be harmed by this patch > - I guess you'd want to initialize lots of CacheExprs but never make > use of the caching usefully? As I mentioned in the first letter about this feature it will be useful for such text search queries [1]: SELECT COUNT(*) FROM messages WHERE body_tsvector @@ to_tsquery('postgres'); And I'm not sure that it is logical to precalculate stable and immutable functions themselves, but not to precalculate expressions that behave like stable/immutable functions; precalculate some types of operators and not to precalculate others (ScalarArrayOpExpr, RowCompareExpr). My patch solves the problem that not all nodes are simplified in eval_const_expressions_mutator (for example, ScalarArrayOpExpr) and consts of other types now behave more like ordinary consts (for example, composite types, coerce expressions, ConvertRowtypeExpr). > It could also be useful to test things like TPC-H to see if you get an > improvement. I saw the examples of queries in TPC-H tests. If I'm not wrong they are not the target tests for this functionality (nothing will be precalculated). But it's a good idea to check that there's no a performance degradation on them too. [1] https://www.postgresql.org/message-id/ba261b9fc25dea4069d8ba9a8fcadf35%40postgrespro.ru -- Marina Polyakova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: