[HACKERS] Exposing ArrayBuildState to pl/pgsql
For many aggregate functions it is necessary to store the actual column values in the aggregate state and then do whatever calculation across them in the final function. In many examples this is done by using array_append as the sfunc and then a custom plpgsql function as the final function operating on the array. Unfortunately array_append allocates a new array on each call which makes it unusably slow for any large aggregates. The speed of allocating an array is largely fixed by using array_agg_transfn as the state function and a custom C function as the final function, however this requires writing/compiling/packaging the aggregate as an extension written in C when often the final function does very simple operations on the array that could easily be expressed in a higher level language for convenience. From what I can tell ArrayBuildState is defined as type internal because it is a pointer being passed by value. Is this in fact the limitation that requires it to be type 'internal' or is there another limitation? Is there someway to expose ArrayBuildState as a type or even another way to do a 'fast' array collection of an aggregate that is to be operated on by a final function written in sql or any of the pl-languages? Thanks Dave Byrne NOTICE: This message and any attachments are intended only for the use of the addressee and may contain confidential, proprietary and/or privileged information. If you are not the intended recipient, any review, use, distribution, dissemination or copying of this email is prohibited. If you have received this email in error, please notify the sender by replying to this message and delete this email immediately. Securities trading, account management, and investment banking services are offered by MDB Capital Group LLC, a registered broker-dealer and member of FINRA and SIPC. Unless clearly stated, nothing herein shall be construed to be an offer to sell, nor a solicitation of an offer to buy, any financial product. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rc1 or beta4?
On 08/17/2011 09:42 AM, Tom Lane wrote: I think you're imagining a lot more structure than actually exists in this project ;-). Anybody can edit that page, and there's no necessary consequence of something being written there. It's just notes to help us keep track of issues, not something graven on stone tablets. The pg_upgrade thing is listed as a beta blocker because I put it there --- but that's just my opinion. If it had proven hard to fix we might have concluded that we wouldn't let it block a beta release. If the plpython thing is a new crash that didn't exist before 9.1, my feeling is that it's a blocker. regards, tom lane I can confirm that the bug in pg_upgrade has been fixed with Bruce's patch in commit 2411fbdac448045a23eebf4f0dbfd5790ebad720 Thanks Dave Byrne -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Possible Bug in pg_upgrade
On 08/11/2011 12:02 AM, Peter Eisentraut wrote: On ons, 2011-08-10 at 18:53 -0400, Tom Lane wrote: Dave Byrnedby...@mdb.com writes: Attached is a patch that skips orphaned temporary relations in pg_upgrade if they are lingering around. It works for 9.0 - 9.1 upgrades, however I wasn't able to tell when pg_class.relistemp was added so if it was unavailable in versions prior to 9.0 an additional check will have to be added. I'm inclined to think the correct fix is to revert the assumption that the old and new databases contain exactly the same number of tables ... that seems to have a lot of potential failure modes besides this one. It's basically checking whether pg_dump -s worked. That doesn't seem like a good use of time. If anyone has a suggestion for a better approach I'm happy to work on it and amend the patch. It is certainly is a corner case but it bit me when preparing for the upcoming 9.1 release. I would imagine others will hit it as well. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Possible Bug in pg_upgrade
Beginning with commit 002c105a0706bd1c1e939fe0f47ecdceeae6c52d pg_upgrade will fail if there are orphaned temp tables in the current database with the message 'old and new databases postgres have a different number of relations' On line 41 of pg_upgrade/info.c pg_upgrade checks that the number of relations are the same but includes orphaned temp tables in the comparison. Is this expected behavior? If so is there a more detailed error message that can be added explain the cause of the failure? It wasn't evident until modified pg_upgrade to show the missing oid's and recognized them as temp tables with oid2name. Dave Byrne Phone: (310) 526-5000 Direct: (310) 526-5021 Email: dby...@mdb.commailto:dby...@mdb.com MDB CAPITAL GROUP LLC Seeing Value Others Do Not, Creating Value Others Can Not. 401 Wilshire Boulevard, Suite 1020 Santa Monica, California 90401 www.mdb.comhttp://www.mdb.com [MDB Capital Group]http://www.mdb.com The IP Investment Bank -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Possible Bug in pg_upgrade
Attached is a patch that skips orphaned temporary relations in pg_upgrade if they are lingering around. It works for 9.0 - 9.1 upgrades, however I wasn't able to tell when pg_class.relistemp was added so if it was unavailable in versions prior to 9.0 an additional check will have to be added. Thanks Dave Byrne -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Wednesday, August 10, 2011 12:29 PM To: Dave Byrne Cc: pgsql-hackers@postgresql.org; Bruce Momjian Subject: Re: [HACKERS] Possible Bug in pg_upgrade Dave Byrne dby...@mdb.com writes: Beginning with commit 002c105a0706bd1c1e939fe0f47ecdceeae6c52d pg_upgrade will fail if there are orphaned temp tables in the current database with the message 'old and new databases postgres have a different number of relations' On line 41 of pg_upgrade/info.c pg_upgrade checks that the number of relations are the same but includes orphaned temp tables in the comparison. Is this expected behavior? Seems like an oversight. regards, tom lane pg_upgrade_tmp.patch Description: pg_upgrade_tmp.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
