Re: final patch - plpgsql: for-in-array - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: final patch - plpgsql: for-in-array
Date
Msg-id AANLkTim_sRK5CnLQHbLwWPNLGMQcxUJqx1MzCTVH+xjU@mail.gmail.com
Whole thread Raw
In response to Re: final patch - plpgsql: for-in-array  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: final patch - plpgsql: for-in-array
List pgsql-hackers
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
>


pgsql-hackers by date:

Previous
From: Steve Singer
Date:
Subject: Re: Patch to add a primary key using an existing index
Next
From: Heikki Linnakangas
Date:
Subject: Re: directory archive format for pg_dump