From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: four minor proposals for 9.5 |
Date: | 2014-03-20 00:26:40 |
Message-ID: | CAFj8pRCWQjbq8Az60gP+QffnvKvf+pF1L7wsmbb8i1UpTfHpsA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2014-03-19 23:31 GMT+01:00 Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>:
> On 03/19/2014 04:34 PM, Pavel Stehule wrote:
> > Hello
> >
> > I wrote a few patches, that we use in our production. These patches
> > are small, but I hope, so its can be interesting for upstream:
> >
> > 1. cancel time - we log a execution time cancelled statements
>
> +1
>
> I even wrote a patch to do this, but it wasn't pretty so I never posted
> it. I would be happy to review yours or revive mine.
>
> > 2. fatal verbose - this patch ensure a verbose log for fatal errors.
> > It simplify a investigation about reasons of error.
>
> +0
>
> > 3. relation limit - possibility to set session limit for maximum size
> > of relations. Any relation cannot be extended over this limit in
> > session, when this value is higher than zero. Motivation - we use lot
> > of queries like CREATE TABLE AS SELECT .. , and some very big results
> > decreased a disk free space too much. It was high risk in our multi
> > user environment. Motivation is similar like temp_files_limit.
>
> -1
>
> Also, I can't find any temp_files_limit setting anywhere.
>
any our server serves a about 100 users per seconds. We have system, that
generate relative complex queries, where some Cartesian products are valid
(although we are not happy). This limits removes a few (but real) critical
issues, when we didn't enough free space on disc. After implementation of
this limit we are able to ensure safe long time production with about 20%
free space. In multiuser environment is more safe to kill some queries than
lost your all production.
>
> > 4. track statement lock - we are able to track a locking time for
> > query and print this data in slow query log and auto_explain log. It
> > help to us with lather slow query log analysis.
>
> -0
>
> > Do you thinking so these patches can be generally useful?
>
> Yes and no, as scored above.
>
> --
> Vik
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-03-20 00:28:08 | Re: four minor proposals for 9.5 |
Previous Message | Pavel Stehule | 2014-03-20 00:19:37 | Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors |