Re: WIP Patch: Precalculate stable functions, infrastructure v1

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

In response to

Responses

Browse pgsql-hackers by date

  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?