Pavel Stehule writes:
> We can introduce new feature without hard dependency on CSV format
Look, the long and the short of it is that there is not consensus
that this measurement is worth creating a new CSV log column for.
And from that, there is also not consensus that it's worth putting
into lo
2014-04-17 7:12 GMT+02:00 Amit Kapila :
> On Mon, Apr 14, 2014 at 6:27 PM, Robert Haas
> wrote:
> > I agree. I don't think the idea of pushing this into the
> > log_line_prefix stuff as a one-off is a very good one. Sure, we could
> > wedge it in there, but we've got an existing precedent that
On Mon, Apr 14, 2014 at 6:27 PM, Robert Haas wrote:
> I agree. I don't think the idea of pushing this into the
> log_line_prefix stuff as a one-off is a very good one. Sure, we could
> wedge it in there, but we've got an existing precedent that everything
> that you can get with log_line_prefix
Pavel Stehule writes:
> 2014-04-14 14:57 GMT+02:00 Robert Haas :
>> I agree. I don't think the idea of pushing this into the
>> log_line_prefix stuff as a one-off is a very good one. Sure, we could
>> wedge it in there, but we've got an existing precedent that everything
>> that you can get with
2014-04-14 14:57 GMT+02:00 Robert Haas :
> On Tue, Apr 8, 2014 at 12:34 PM, Gregory Smith
> wrote:
> > On 4/6/14 2:46 PM, Pavel Stehule wrote:
> >> Proposed options are interesting for "enterprise" using, when you have a
> >> some more smart tools for log entry processing, and when you need a
> c
On Tue, Apr 8, 2014 at 12:34 PM, Gregory Smith wrote:
> On 4/6/14 2:46 PM, Pavel Stehule wrote:
>> Proposed options are interesting for "enterprise" using, when you have a
>> some more smart tools for log entry processing, and when you need a complex
>> view about performance of billions queries -
2014-04-10 5:50 GMT+02:00 Amit Kapila :
> On Tue, Apr 8, 2014 at 9:07 PM, Pavel Stehule
> wrote:
> > 2014-04-08 6:27 GMT+02:00 Amit Kapila :
> >> So do you want to just print lock time for error'd statements, won't
> >> it better to
> >> do it for non-error'd statements as well or rather I feel i
On Tue, Apr 8, 2014 at 9:07 PM, Pavel Stehule wrote:
> 2014-04-08 6:27 GMT+02:00 Amit Kapila :
>> So do you want to just print lock time for error'd statements, won't
>> it better to
>> do it for non-error'd statements as well or rather I feel it can be more
>> useful
>> for non-error statements?
2014-04-08 18:34 GMT+02:00 Gregory Smith :
> On 4/6/14 2:46 PM, Pavel Stehule wrote:
>
>>
>> Proposed options are interesting for "enterprise" using, when you have a
>> some more smart tools for log entry processing, and when you need a complex
>> view about performance of billions queries - when
On 4/6/14 2:46 PM, Pavel Stehule wrote:
Proposed options are interesting for "enterprise" using, when you have
a some more smart tools for log entry processing, and when you need a
complex view about performance of billions queries - when cancel time
and lock time is important piece in mosaic
2014-04-08 6:27 GMT+02:00 Amit Kapila :
> On Mon, Apr 7, 2014 at 12:16 AM, Pavel Stehule
> wrote:
> > 2014-04-04 6:51 GMT+02:00 Amit Kapila :
> >> On Tue, Apr 1, 2014 at 11:42 PM, Pavel Stehule >
> >> wrote:
> >> > 2014-03-27 17:56 GMT+01:00 Pavel Stehule :
> >> >> So I'll prepare a some prototy
On Mon, Apr 7, 2014 at 12:16 AM, Pavel Stehule wrote:
> 2014-04-04 6:51 GMT+02:00 Amit Kapila :
>> On Tue, Apr 1, 2014 at 11:42 PM, Pavel Stehule
>> wrote:
>> > 2014-03-27 17:56 GMT+01:00 Pavel Stehule :
>> >> So I'll prepare a some prototypes in next month for
>> >>
>> >> 1. log a execution time
2014-04-04 6:51 GMT+02:00 Amit Kapila :
> On Tue, Apr 1, 2014 at 11:42 PM, Pavel Stehule
> wrote:
> > 2014-03-27 17:56 GMT+01:00 Pavel Stehule :
> >> So I'll prepare a some prototypes in next month for
> >>
> >> 1. log a execution time for cancelled queries,
> >> 2. track a query lock time
> >>
>
On Tue, Apr 1, 2014 at 11:42 PM, Pavel Stehule wrote:
> 2014-03-27 17:56 GMT+01:00 Pavel Stehule :
>> So I'll prepare a some prototypes in next month for
>>
>> 1. log a execution time for cancelled queries,
>> 2. track a query lock time
>>
>
> When I though about this proposal, I found so our impl
2014-03-27 17:56 GMT+01:00 Pavel Stehule :
> Hello
>
> After week, I can to evaluate a community reflection:
>
>
> 2014-03-19 16:34 GMT+01:00 Pavel Stehule :
>
> 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
Hello
After week, I can to evaluate a community reflection:
2014-03-19 16:34 GMT+01:00 Pavel Stehule :
> 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 ca
Hello
2014-03-20 1:28 GMT+01:00 Josh Berkus :
> Pavel,
>
> > 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
>
> Manually cancelled? state
2014-03-20 9:47 GMT+01:00 Mark Kirkwood :
> On 20/03/14 20:08, Pavel Stehule wrote:
>
>>
>>
>>
>> 2014-03-20 7:25 GMT+01:00 Mark Kirkwood > Also I think this would probably only make sense for TEMPORARY
>> tables - otherwise you can get this sort of thing going on:
>>
>> - you create a
On 20/03/14 20:08, Pavel Stehule wrote:
2014-03-20 7:25 GMT+01:00 Mark Kirkwood
Sorry Pavel - what you have said above is difficult for me to understand
- if the limit is intended as a *session* limit then concurrent activity
from multiple sessions makes it behave - well - strangely to say
2014-03-20 7:25 GMT+01:00 Mark Kirkwood :
> On 20/03/14 13:28, Josh Berkus wrote:
>
> 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 us
2014-03-20 5:36 GMT+01:00 Amit Kapila :
> On Wed, Mar 19, 2014 at 9:04 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 ti
On 20/03/14 13:28, Josh Berkus wrote:
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
On Wed, Mar 19, 2014 at 9:04 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
>
> 2. fatal verbose - this patch
2014-03-20 1:28 GMT+01:00 Josh Berkus :
> Pavel,
>
> > 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
>
> Manually cancelled? statement_tim
Pavel,
> 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
Manually cancelled? statement_timeout?
Anyway, +1 to add the time to the existing log
2014-03-19 23:31 GMT+01:00 Vik Fearing :
> 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 cancelle
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 i
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
2. fatal verbose - this patch ensure a verbose log for fatal errors. It
simplify a investigation
28 matches
Mail list logo
