From: | Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, Andres Freund <andres(at)anarazel(dot)de>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: WIP Patch: Precalculate stable functions, infrastructure v1 |
Date: | 2017-07-21 14:39:00 |
Message-ID: | 9caa5cc6be9c41140915dcdf8e4847a6@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2017-07-21 14:39:42 | Re: [GENERAL] huge RAM use in multi-command ALTER of table heirarchy |
Previous Message | Tom Lane | 2017-07-21 14:33:03 | Re: More optimization effort? |