Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity. - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.
Date
Msg-id CAASwCXcGCRgLLDNBKD+zdob_5iJ-cdtuSj=5ynGz_R5ckiGCmQ@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.
List pgsql-hackers
On Sat, Mar 12, 2016 at 4:08 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> I don't think my experience in this area is as deep as you seem to
> think.  I can tell you that most of the requests EnterpriseDB gets for
> PL/pgsql enhancements involve wanting it to be more like Oracle's
> PL/SQL, which of course has very little overlap with the stuff that
> you're interested in.

Do you know who could possibly be more experienced
with companies who are heavy users of PL/pgSQL in the community?

and/or,

Do you know of any companies who officially are heavy users of PL/pgSQL?

The only other company I can think of is Zalado, but of course there
are many more,
I just wish I knew their names, because I want to compile a wish list with
proposed changes from as many companies who are heavy users of
PL/pgSQL as possible.

That's the only way to push this forward. As you say, we need a
consensus and input
from a broad range of heavy users, not just from people on this list
with feelings
and opinions who might not actually be heavy users themselves.

Of course almost everybody on this list uses PL/pgSQL from time to
time or even daily,
but it's a completely different thing to write an entire backend
system in the language,
it's first then when you start to become really excited of e.g. not
having to type
at least 30 characters of text every time you do an UPDATE/INSERT
to be sure you modified exactly one row.



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: amcheck (B-Tree integrity checking tool)
Next
From: Tom Lane
Date:
Subject: Re: Performance improvement for joins where outer side is unique