Re: Index on immutable function call - Mailing list pgsql-general

From Alban Hertroys
Subject Re: Index on immutable function call
Date
Msg-id F63132B0-DE36-49C0-9404-4C12CB0C552F@solfertje.student.utwente.nl
Whole thread Raw
In response to Re: Index on immutable function call  ("Philippe Lang" <philippe.lang@attiksystem.ch>)
List pgsql-general
> Hi,
>
> It does!
>
> With your index alone:
>
> ---------------------------
> Bitmap Heap Scan on indexed_table  (cost=815.17..10106.08 rows=33333
> width=12) (actual time=7.796..236.722 rows=50116 loops=1)
>  Recheck Cond: (data1 > this_is_a_long_transformation(data2))
>  ->  Bitmap Index Scan on transform_index  (cost=0.00..806.84
> rows=33333 width=0) (actual time=7.665..7.665 rows=50116 loops=1)
> Total runtime: 459.380 ms
> ---------------------------
>
> That works just fine, but is there maybe a way of creating a slighly
> more "generic" index? If I change the ">" with a "<" in the query, index
> cannot of course be used. According to documentation, answer seems to be
> "no"...

I have to say I'm a bit surprised this works, as the database still needs to check all these rows for existence.
Apparentlythe index is sufficiently selective with your database tuning parameters. 

That said, if this works then a combined index on (data1, this_is_a_long_transformation(data2)) will probably also work
andgive you the flexibility you need. 

Alban Hertroys

--
Screwing up is the best way to attach something to the ceiling.


!DSPAM:737,4b55875b10601514515279!



pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: Index on immutable function call
Next
From: "A. Kretschmer"
Date:
Subject: Re: Index on immutable function call