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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
