do such a thing would look.
Thanks in advance for the help, and keep up the great work. PG8.3 is an
amazing piece of software and it blows me away how much more advanced it gets
with every release.
Bart Grantham
VP of R&D
Logicworks Inc. - Complex and Managed Hosting
;ve shaved about 30% off the query time now that I can
use RETURN QUERY.
BG
-Original Message-
From: Pavel Stehule [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2008 7:51 AM
To: Bart Grantham
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Alias for function return buffer
ssage-
From: Pavel Stehule [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2008 7:51 AM
To: Bart Grantham
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Alias for function return buffer in pl/pgsql?
>
>
> Bonus question - if I rewrite the first FOR loop as:
>
&g
we're pretty familiar with PG and would
be happy to talk to anyone about hosting needs they may have.
Thanks for listening, and again please let me know if there is further testing
we can do to help get to the bottom of this Opteron/Xeon performance
discrepancy.
Bart Grantham
VP of R&D
Logicworks, Inc.
www.logicworks.net
Hello, all. I work for a Manhattan ISP and have developed an internal
systems management/housekeeping app on php/postgres 7.4. I am trying to
speed up some bits with stored procedures and have had great success,
except I've now run into a bit of trouble. It comes down to this:
# SELECT * FRO
Hello again. I had a problem a few weeks ago with using IN ( some_array
) having really rough performance. Special thanks to Ron Mayer for the
suggestion of using int_array_enum(some_array) to join against. I had
to upgrade to PG8 but that technique works really well. Now I have a
question
Summary: depending on the value, the planner will sometimes choose a seq
scan, sometimes an index scan. The former produces terrible performace,
the latter great performance.
The long story: we had a disk failure (NOT the disk the db was on) and
the machine's system disk had to be rebuilt fro
That's me and my project listed there. Glad to give PG the good press
it deserves, it's the least I could do. It's been a great db for us,
and we're looking forward to 8.1.
And thanks for the help that I received on the mailing list a few months
back that directly impacted this project. It
