On Tue, Oct 4, 2011 at 9:42 AM, Joshua Kramer <josh@globalherald.net> wrote:
>
>> I see this as a wake up call that our advocacy needs to focus on the
>> case studies, like that of Urban Airship, to demonstrate how to scale
>> infrastructure with Postgres. Keeping this information either secret
>> or difficult to find results in throwing out or scaling back use of
>> Postgres.
>
> Hey, Ned Lilly - are you on this list? Do you have any examples of highly
> scaled xTuple installations? (For those who are unaware, xTuple is an open
> source ERP solution based on a Qt frontend. All of the business logic
> resides in Postgres stored procedures.)
>
I can't speak for xTuple, but for LedgerSMB, we have at least one user
who processes payment runs of 5k invoices at a time via Perl/CGI and
PostgreSQL (total of 20k invoices per week, and expecting this number
to rise) with the main logic handled in stored procedures. If it was
just a matter of selection, we could run that selection in a few
seconds but a lot of info has to be written to the db so that states
don't change between web requests. Consequently it takes only a bit
longer than that. The real bottleneck is actually the CGI scripts
which generate HTML forms representing 5000 invoices.......
Keep in mind this is being run against a database with a million
invoices in it, and probably 10 million invoice lines, and a portion
of the lines must be summed up to ensure the invoice is fully paid
off. We have found PostgreSQL performs very well.
In general, I have found that tuning stored procedures is easier than
tuning ORM-generated queries, which is why I am convinced there must
be more to the story than we are being told.
Best Wishes,
Chris Travers
