Hello
I spent last two days a searching how to solve this problem better.
Probably I removed a issue with toasting. But I found other issue,
that wasn't discussed before. This issue is only seq access to items
via array_seek function. I though about some variable that stores a
last accessed field and last used subscript - but there isn't a good
place where this info can be stored (maybe in ArrayType). Other issues
are a arrays with a null bitmap. It is difficult to say if this cache
can have a positive effect - maybe yes - for large arrays. Problem is
in possible a increase of price for random access to array. And there
are not any "hint", that helps with specification about access to
array.
I don't think so searching inside expr. plan is a good idea. Is way to
have more code, more complexity. If we will do it, then more important
are accelerations of expression var = var + 1; var = var || var; or
some else.
So, please, I know, so you and Tom are busy, but try to spend a few
time about this problem before you are definitely reject this idea.
With my last patch (removing a toasting issue) the classic access to
array should be usable. But still any direct access to array from PL
executor is 20% faster - depends on array type. Maybe it is useless
discus - and all can be solved with possible support SRF inside simple
expression, but I don't know when it will be possible.
Regards
Pavel Stehule
** CAUTION: if you change the header for ordinary arrays you will also* need to change the headers for oidvector and
int2vector!*/
>
> I think it should be marked rejected. I don't think Tom is likely to
> ever be in favor of a syntax change here, and while I hesitate to deal
> in absolutes, I don't think I will be either, and certainly not
> without a lot more work on improving the performance of the existing
> constructs. In particular, this seems like something that really
> ought to be pursued:
>
> http://archives.postgresql.org/pgsql-hackers/2010-11/msg01177.php
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
