Re: proposal for 9.5: monitoring lock time for slow queries

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: MauMau <maumau307(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal for 9.5: monitoring lock time for slow queries
Date: 2014-08-13 12:22:21
Message-ID: CAFj8pRCNqw5TTtN6wnUsMw=oViwEu30ZsTJy=SH5UXzEd46KAw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-08-13 13:59 GMT+02:00 MauMau <maumau307(at)gmail(dot)com>:

> From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
>
> isn't it too heavy?
>>
>
> Are you concerned about the impactof collection overhead on the queries
> diagnosed? Maybe not light, but I'm optimistic. Oracle has the track
> record of long use, and MySQL provides performance schema starting from 5.6.

partially, I afraid about total performance (about impact on IO) - when we
use a usual tables, then any analyses without indexes are slow, so you need
a indexes, and we cannot deferred index update. You should thinking about
retention policy - and without partitioning you got massive deletes. So I
cannot to imagine a usage of table based solution together with some higher
load. Our MVCC storage is not practical for storing only inserted data, and
some custom storage has no indexes - so this design is relative big project.

>
>
> I have just terrible negative experience with Vertica, where this design
>> is
>> used - almost all information about queries are available, but any query
>> to
>> related tables are terrible slow, so I am inclined to more simple design
>> oriented to log based solution. Table based solutions is not practical
>> when
>> you exec billions queries per day. I understand to motivation, but I
>> afraid
>> so it can be very expensive and slow on highly load servers.
>>
>
> Which do you mean by "query related to tables", the queries from
> applications being diagnosed, or the queries that diagnose the performance
> using statistics views?
>
> Could you elaborate on your experience with Vertica? That trouble may be
> just because Vertica's implementation is not refined.
>
>
sure - Vertica is not mature database. More it has only one storage type
optimized for OLAP, what is wrong for long catalog, and for working with
performance events too.

> I understand the feeling of being inclined to log based solution for its
> implementation simplicity. However, the server log is difficult or
> impossible to access using SQL queries. This prevents the development of
> performance diagnostics functionality in GUI administration tools. Also,
> statistics views allow for easy access on PAAS like Amazon RDS and Heroku.
>

I prefer a possibility to read log via SQL (maybe some FDW) than use tables
for storing log. These tables can be relative very large in few days - and
we cannot to write specialized engine like MySQL simply.

Pavel

>
> Regards
> MauMau
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-08-13 13:15:46 Re: WAL format and API changes (9.5)
Previous Message MauMau 2014-08-13 11:59:17 Re: proposal for 9.5: monitoring lock time for slow queries