Surjective functional indexes

classic Classic list List threaded Threaded
83 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Surjective functional indexes

konstantin knizhnik
Right now Postgres determines whether update operation touch index or
not based only on set of the affected columns.
But in case of functional indexes such policy quite frequently leads to
unnecessary index updates.
For example, functional index are widely use for indexing JSON data:
info->>'name'.

JSON data may contain multiple attributes and only few of them may be
affected by update.
Moreover, index is used to build for immutable attributes (like "id",
"isbn", "name",...).

Functions like (info->>'name') are named "surjective" ni mathematics.
I have strong feeling that most of functional indexes are based on
surjective functions.
For such indexes current Postgresql index update policy is very
inefficient.  It cause disabling of hot updates
and so leads to significant degrade of performance.

Without this patch Postgres is slower than Mongo on YCSB benchmark with
(50% update,50 % select)  workload.
And after applying this patch Postgres beats Mongo at all workloads.

My proposal is to check value of function for functional indexes instead
of just comparing set of effected attributes.
Obviously, for some complex functions it may  have negative effect on
update speed.
This is why I have added "surjective" option to index. By default it is
switched on for all functional indexes (based on my assumption
that most functions used in functional indexes are surjective). But it
is possible to explicitly disable it and make decision weather index
needs to be updated or not only based on set of effected attributes.


--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

surjective-index.patch (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

Tom Lane-2
Konstantin Knizhnik <[hidden email]> writes:
> My proposal is to check value of function for functional indexes instead
> of just comparing set of effected attributes.
> Obviously, for some complex functions it may  have negative effect on
> update speed.
> This is why I have added "surjective" option to index.

This seems overcomplicated.  We would have to compute the function
value at some point anyway.  Can't we refactor to do that earlier?

                        regards, tom lane


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

Andres Freund
On 2017-05-25 12:37:40 -0400, Tom Lane wrote:
> Konstantin Knizhnik <[hidden email]> writes:
> > My proposal is to check value of function for functional indexes instead
> > of just comparing set of effected attributes.
> > Obviously, for some complex functions it may  have negative effect on
> > update speed.
> > This is why I have added "surjective" option to index.
>
> This seems overcomplicated.  We would have to compute the function
> value at some point anyway.  Can't we refactor to do that earlier?

Yea, that'd be good. Especially if we were to compute the expressions
for all indexes in one go - doing that in other places (e.g. aggregate
transition values) yielded a good amount of speedup.  It'd be even
larger if we get JITing of expressions.  It seems feasible to do so for
at least the nodeModifyTable case.

I wonder if there's a chance to use such logic alsofor HOT update
considerations, but that seems harder to do without larger layering
violations.

- Andres


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

konstantin knizhnik
In reply to this post by Tom Lane-2


On 25.05.2017 19:37, Tom Lane wrote:

> Konstantin Knizhnik <[hidden email]> writes:
>> My proposal is to check value of function for functional indexes instead
>> of just comparing set of effected attributes.
>> Obviously, for some complex functions it may  have negative effect on
>> update speed.
>> This is why I have added "surjective" option to index.
> This seems overcomplicated.  We would have to compute the function
> value at some point anyway.  Can't we refactor to do that earlier?
>
> regards, tom lane


Check for affected indexes/applicability of HOT update and update of
indexes themselves is done in two completely different parts of code.
And if we find out that values of indexed expressions are not changed,
then we can use HOT update and indexes should not be updated
(so calculated value of function is not needed). And it is expected to
be most frequent case.

Certainly, if value of indexed expression is changed, then we can avoid
redundant calculation of function by storing result of calculations
somewhere.
But it will greatly complicate all logic of updating indexes. Please
notice, that if we have several functional indexes and only one of them
is actually changed,
then in any case we can not use HOT and have to update all indexes. So
we do not need to evaluate values of all indexed expressions. We just
need to find first
changed one. So we should somehow keep track values of which expression
are calculated and which not.

One more argument. Originally Postgres evaluates index expression only
once (when inserting new version of tuple to the index).
Now (with this patch) Postgres has to evaluate expression three times in
the worst case: calculate the value of expression for old and new tuples
to make a decision bout hot update,
and the evaluate it once again when performing index update itself. Even
if I managed to store somewhere calculated value of the expression, we
still have to perform
twice more evaluations than before. This is why for expensive functions
or for functions defined for frequently updated attributes (in case of
JSON) such policy should be disabled.
And for non-expensive functions extra overhead is negligible. Also there
is completely no overhead if indexed expression is not actually changed.
And it is expected to be most frequent case.

At least at the particular example with YCSB benchmark, our first try
was just to disable index update by commenting correspondent check of
updated fields mask.
Obviously there are no extra function calculations in this case. Then I
have implemented this patch. And performance is almost the same.
This is why I think that simplicity and modularity of code is more
important here than elimination of redundant function calculation.


--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

Peter Eisentraut-6
In reply to this post by konstantin knizhnik
On 5/25/17 12:30, Konstantin Knizhnik wrote:
> Functions like (info->>'name') are named "surjective" ni mathematics.

A surjective function is one where each value in the output type can be
obtained by some input value.  That's not what you are after here.  The
behavior you are describing is a not-injective function.

I think you are right that in practice most functions are not injective.
 But I think there is still quite some difference between a function
like the one you showed that selects a component from a composite data
structure and, for example, round(), where in practice any update is
likely to change the result of the function.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

konstantin knizhnik
On 05/27/2017 09:50 PM, Peter Eisentraut wrote:

> On 5/25/17 12:30, Konstantin Knizhnik wrote:
>> Functions like (info->>'name') are named "surjective" ni mathematics.
> A surjective function is one where each value in the output type can be
> obtained by some input value.  That's not what you are after here.  The
> behavior you are describing is a not-injective function.
>
> I think you are right that in practice most functions are not injective.
>   But I think there is still quite some difference between a function
> like the one you showed that selects a component from a composite data
> structure and, for example, round(), where in practice any update is
> likely to change the result of the function.
>
Thank you, I will rename "surjective" parameter to "injective" with "false" as default value.
Concerning "round" and other similar functions - obviously there are use cases when such functions are used for
functional indexes. This is why I want to allow user to make a choice and this is the reason of introducing this parameter.
The question is the default value of this parameter: should we by default preserve original Postgres behavior:
check only affected set of keys or should we pay extra cost for calculating value of the function (even if we managed to store
calculated value of the indexes expression for new tuple, we still have to calculate it for old tuple, so function will be calculated
at least twice more times).

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

apt.postgresql.org repository
Re: Konstantin Knizhnik 2017-05-29 <[hidden email]>

> On 05/27/2017 09:50 PM, Peter Eisentraut wrote:
> > On 5/25/17 12:30, Konstantin Knizhnik wrote:
> > > Functions like (info->>'name') are named "surjective" ni mathematics.
> > A surjective function is one where each value in the output type can be
> > obtained by some input value.  That's not what you are after here.  The
> > behavior you are describing is a not-injective function.
> >
> > I think you are right that in practice most functions are not injective.
> >   But I think there is still quite some difference between a function
> > like the one you showed that selects a component from a composite data
> > structure and, for example, round(), where in practice any update is
> > likely to change the result of the function.
> >
> Thank you, I will rename "surjective" parameter to "injective" with "false" as default value.

I think the term you were looking for is "projection".

https://en.wikipedia.org/wiki/Projection_(set_theory)

Christoph


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

Sven R. Kunze-2
On 29.05.2017 19:21, Christoph Berg wrote:
> I think the term you were looking for is "projection".
> https://en.wikipedia.org/wiki/Projection_(set_theory)

Maybe, I am seeing too much of a connection here but recently Raymond
Hettinger held a very interesting talk [1] at PyCon 2017.

For those without the time or bandwidth to watch: it describes the
history of the modern dict in Python in several steps.

1) avoiding having a database scheme with columns and rows and indexes
2) introducing hashing with bucket lists
3...6) several improvements
7) in the end looks like a database table with indexes again ;)

If you have the time, just go ahead and watch the 30 min video. He can
explain things definitely better than me.


In order to draw the line back on-topic, if I am not completely
mistaken, his talks basically shows that over time even datastructures
with different APIs such as dicts (hashes, maps, sets, etc.) internally
converge towards a relational-database-y design because of performance
and resources reasons.


Thus let me think that also in the on-topic case, we might best be
supporting the much narrow use-case of "Projection" (a term also used in
relation database theory btw. ;-) ) instead of non-surjective functions.


Cheers,
Sven


[1] https://www.youtube.com/watch?v=npw4s1QTmPg


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

Sven R. Kunze-2
On 29.05.2017 21:25, Sven R. Kunze wrote:
> [...] non-surjective functions.
non-injective of course


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

konstantin knizhnik
In reply to this post by apt.postgresql.org repository


On 29.05.2017 20:21, Christoph Berg wrote:
>
> I think the term you were looking for is "projection".
>
> https://en.wikipedia.org/wiki/Projection_(set_theory)

I have already renamed parameter from "surjective" to "injective".
But I am ok to do do one more renaming to "projection" if it will be
considered as better alternative.
 From my point of view, "projection" seems to be clearer for people
without mathematical background,
but IMHO this term is overloaded in DBMS context. The irony is that in
Wikipedia "projection" is explained using "surjection" term:)

>
> Christoph

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

apt.postgresql.org repository
Re: Konstantin Knizhnik 2017-05-30 <[hidden email]>

>
>
> On 29.05.2017 20:21, Christoph Berg wrote:
> >
> > I think the term you were looking for is "projection".
> >
> > https://en.wikipedia.org/wiki/Projection_(set_theory)
>
> I have already renamed parameter from "surjective" to "injective".
> But I am ok to do do one more renaming to "projection" if it will be
> considered as better alternative.
> From my point of view, "projection" seems to be clearer for people without
> mathematical background,
> but IMHO this term is overloaded in DBMS context.

With mathematical background, I don't see how your indexes would
exploit surjective or injective properties of the function used. What
you are using is that ->> projects a json value to one of its
components, i.e. the projection/function result does not depend on the
other attributes contained.

> The irony is that in Wikipedia "projection" is explained using
> "surjection" term:)

For the equivalence classes part, which isn't really connected to your
application.

Christoph


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

konstantin knizhnik
Attached please find rebased version of the patch.
Now "projection" attribute is used instead of surjective/injective.

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

projection.patch (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

Thomas Munro-3
On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik
<[hidden email]> wrote:
> Attached please find rebased version of the patch.
> Now "projection" attribute is used instead of surjective/injective.

Hi Konstantin,

This still applies but it doesn't compile after commits 2cd70845 and
c6293249.  You need to change this:

      Form_pg_attribute att = RelationGetDescr(indexDesc)->attrs[i];

... to this:

      Form_pg_attribute att = TupleDescAttr(RelationGetDescr(indexDesc), i);

Thanks!

--
Thomas Munro
http://www.enterprisedb.com


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

Simon Riggs
On 1 September 2017 at 05:40, Thomas Munro
<[hidden email]> wrote:

> On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik
> <[hidden email]> wrote:
>> Attached please find rebased version of the patch.
>> Now "projection" attribute is used instead of surjective/injective.
>
> Hi Konstantin,
>
> This still applies but it doesn't compile after commits 2cd70845 and
> c6293249.  You need to change this:
>
>       Form_pg_attribute att = RelationGetDescr(indexDesc)->attrs[i];
>
> ... to this:
>
>       Form_pg_attribute att = TupleDescAttr(RelationGetDescr(indexDesc), i);
>
> Thanks!

Does the patch work fully with that change? If so, I will review.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

konstantin knizhnik

On 01.09.2017 09:25, Simon Riggs wrote:

> On 1 September 2017 at 05:40, Thomas Munro
> <[hidden email]> wrote:
>> On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik
>> <[hidden email]> wrote:
>>> Attached please find rebased version of the patch.
>>> Now "projection" attribute is used instead of surjective/injective.
>> Hi Konstantin,
>>
>> This still applies but it doesn't compile after commits 2cd70845 and
>> c6293249.  You need to change this:
>>
>>        Form_pg_attribute att = RelationGetDescr(indexDesc)->attrs[i];
>>
>> ... to this:
>>
>>        Form_pg_attribute att = TupleDescAttr(RelationGetDescr(indexDesc), i);
>>
>> Thanks!
> Does the patch work fully with that change? If so, I will review.
>
Attached please find rebased version of the patch.
Yes, I checked that it works after this fix.
Thank you in advance for review.

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

projection.patch (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

Simon Riggs
On 1 September 2017 at 09:47, Konstantin Knizhnik
<[hidden email]> wrote:

>
> On 01.09.2017 09:25, Simon Riggs wrote:
>>
>> On 1 September 2017 at 05:40, Thomas Munro
>> <[hidden email]> wrote:
>>>
>>> On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik
>>> <[hidden email]> wrote:
>>>>
>>>> Attached please find rebased version of the patch.
>>>> Now "projection" attribute is used instead of surjective/injective.
>>>
>>> Hi Konstantin,
>>>
>>> This still applies but it doesn't compile after commits 2cd70845 and
>>> c6293249.  You need to change this:
>>>
>>>        Form_pg_attribute att = RelationGetDescr(indexDesc)->attrs[i];
>>>
>>> ... to this:
>>>
>>>        Form_pg_attribute att = TupleDescAttr(RelationGetDescr(indexDesc),
>>> i);
>>>
>>> Thanks!
>>
>> Does the patch work fully with that change? If so, I will review.
>>
> Attached please find rebased version of the patch.
> Yes, I checked that it works after this fix.
> Thank you in advance for review.

Thanks for the patch. Overall looks sound and I consider that we are
working towards commit for this.

The idea is that we default "projection = on", and can turn it off in
case the test is expensive. Why bother to have the option? (No docs at
all then!) Why not just evaluate the test and autotune whether to make
the test again in the future? That way we can avoid having an option
completely. I am imagining collecting values on the relcache entry for
the index.

To implement autotuning we would need to instrument the execution. We
could then display the collected value via EXPLAIN, so we could just
then use EXPLAIN in your tests rather than implementing a special
debug mode just for testing. We could also pass that information thru
to stats as well.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

konstantin knizhnik


On 12.09.2017 19:28, Simon Riggs wrote:

> On 1 September 2017 at 09:47, Konstantin Knizhnik
> <[hidden email]> wrote:
>> On 01.09.2017 09:25, Simon Riggs wrote:
>>> On 1 September 2017 at 05:40, Thomas Munro
>>> <[hidden email]> wrote:
>>>> On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik
>>>> <[hidden email]> wrote:
>>>>> Attached please find rebased version of the patch.
>>>>> Now "projection" attribute is used instead of surjective/injective.
>>>> Hi Konstantin,
>>>>
>>>> This still applies but it doesn't compile after commits 2cd70845 and
>>>> c6293249.  You need to change this:
>>>>
>>>>         Form_pg_attribute att = RelationGetDescr(indexDesc)->attrs[i];
>>>>
>>>> ... to this:
>>>>
>>>>         Form_pg_attribute att = TupleDescAttr(RelationGetDescr(indexDesc),
>>>> i);
>>>>
>>>> Thanks!
>>> Does the patch work fully with that change? If so, I will review.
>>>
>> Attached please find rebased version of the patch.
>> Yes, I checked that it works after this fix.
>> Thank you in advance for review.
> Thanks for the patch. Overall looks sound and I consider that we are
> working towards commit for this.
>
> The idea is that we default "projection = on", and can turn it off in
> case the test is expensive. Why bother to have the option? (No docs at
> all then!) Why not just evaluate the test and autotune whether to make
> the test again in the future? That way we can avoid having an option
> completely. I am imagining collecting values on the relcache entry for
> the index.

Autotune is definitely good thing. But I do not think that excludes
having explicit parameter for manual tuning.
For some functional indexes DBA or programmer knows for sure that it
doesn't perform projection.
For example if it translates or changes encoding of original key. It
seems to me that we should make it possible to
declare this index as non-projective and do not rely on autotune.

Also I have some doubts concerning using autotune in this case. First of
all it is very hard to estimate complexity of test.
How can we measure it? Calculate average execution time? It can vary for
different systems and greatly depends on system load...
Somehow calculate cost of indexed expression? It may be also not always
produce expected result.

Moreover, in some cases test may be not expensive, but still useless, if
index expression specifies one-to-one mapping (for example function
reversing key).
Autotone will never be able to reliable determine that indexed
expression is projection or not.

It seems to be more precise to compare statistic for source column and
index expression.
If them are similar, then most likely index expression is not a
projection...
I will think more about it.

> To implement autotuning we would need to instrument the execution. We
> could then display the collected value via EXPLAIN, so we could just
> then use EXPLAIN in your tests rather than implementing a special
> debug mode just for testing. We could also pass that information thru
> to stats as well.
>

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

apt.postgresql.org repository
In reply to this post by konstantin knizhnik
Re: Konstantin Knizhnik 2017-09-01 <[hidden email]>
> +       Functional index is based on on projection function: function which extract subset of its argument.
> +       In mathematic such functions are called non-injective. For injective function if any attribute used in the indexed
> +       expression is changed, then value of index expression is also changed.

This is Just Wrong. I still think what you are doing here doesn't have
anything to do with the function being injective or not.

Christoph


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

konstantin knizhnik


On 13.09.2017 10:51, Christoph Berg wrote:
> Re: Konstantin Knizhnik 2017-09-01 <[hidden email]>
>> +       Functional index is based on on projection function: function which extract subset of its argument.
>> +       In mathematic such functions are called non-injective. For injective function if any attribute used in the indexed
>> +       expression is changed, then value of index expression is also changed.
> This is Just Wrong. I still think what you are doing here doesn't have
> anything to do with the function being injective or not.

Sorry, can you please explain what is wrong?
The problem I am trying to solve comes from particular use case:
functional index on part of JSON column.
Usually such index is built for persistent attributes, which are rarely
changed, like ISBN...
Right now any update of JSON column disables hot update. Even if such
update doesn't really affect index.
So instead of disabling HOT juts based on mask of modified attributes, I
suggest to compare old and new value of index expression.

Such behavior can significantly (several times) increase performance.
But only for "projection" functions.
There was long discussion in this thread about right notion for this
function (subjective,  non-injective,  projection).
But I think criteria is quite obvious.

Simon propose eliminate "projection" property and use autotune to
determine optimal behavior.
I still think that such option will be useful, but we can really use
statistic to compare number of unique values for index function and for
it's argument(s).
If them are similar, then most likely the function is injective, so it
produce different result for different attributes.
Then there is no sense to spend extra CPU time, calculating old and new
values of the function.
This is what I am going to implement now.

So I will be please if you more precisely explain your concerns and
suggestions (if you have one).

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Surjective functional indexes

apt.postgresql.org repository
Re: Konstantin Knizhnik 2017-09-13 <[hidden email]>

>
>
> On 13.09.2017 10:51, Christoph Berg wrote:
> > Re: Konstantin Knizhnik 2017-09-01 <[hidden email]>
> > > +       Functional index is based on on projection function: function which extract subset of its argument.
> > > +       In mathematic such functions are called non-injective. For injective function if any attribute used in the indexed
> > > +       expression is changed, then value of index expression is also changed.
> > This is Just Wrong. I still think what you are doing here doesn't have
> > anything to do with the function being injective or not.
>
> Sorry, can you please explain what is wrong?

I don't get why you are reasoning about "projection" ->
"non-injective" -> "injective". Can't you try to explain what this
functionality is about without abusing math terms that just mean
something else in the rest of the world?

Christoph


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
12345