Hi
> On Jul 08, John McKown modulated:
> ...
>> I think the "problem" that he is having is fixable only by changing how
>> PostgreSQL itself works. His problem is a PL/pgSQL function which is
>> 11K lines in length. When invoked, this function is "compiled" into a
>> large tokenized parse tree. This parse tree is only usable in the
>> session which invoked the the function. Apparently this parse tree
>> takes a lot of memory.
It's pleasant to see smart men, And I got here some help.
The most valuable is advice to deploy PgPool or PgBouncer.
Thanks guys. Usually, I don't answer on certain theme.
http://www.joelonsoftware.com/articles/fog0000000018.html
But may be it helps to somebody.
> Right. I'm not entirely sure the original poster wants to hear
> practical solutions,
Of course this answer requires "moral justification" :)
> but I think there are three ways that someone
> familar with Postgres would avoid this type of problem:
> 1. Connection pooling. Set the max connection limit and other tuning
> parameters appropriately for your workload and available
> resources. Don't get into a state as was described (thousands of
> open connections and only hundreds "active"). Make your client
> applications more disciplined.
You are joking :)
They pay us money, and they want easy and cheap decision :))
I can tell a terrible thing, but they can pay money to others :)))
> 2. Buy more RAM. You can easily grow to 512GB in just basic
> dual-socket servers these days. This hardware cost may well
> be worth it to avoid human labor costs.
Thanks cap :))
http://www.reduxsquad.com/wp-content/uploads/2016/02/hotels-com-spring-break-sale-captain-obvious-workout-bathroom-large-8.jpg
> 3. Rewrite or refactor such complex stored procedures in a different
> programming language such as C or Python, so your PL/pgsql stored
> procedures remain small glue around libraries of code. Postgres
> makes it very trivial to extend the system with such procedural
> libraries.
>
Let's read first :)
