Re: Timing events WIP v1

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Craig Ringer <craig(at)2ndQuadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Timing events WIP v1
Date: 2012-12-12 01:43:30
Message-ID: 50C7E142.7030605@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/20/12 8:02 PM, Craig Ringer wrote:
> On 11/20/2012 04:48 PM, Pavel Stehule wrote:

>> I don't like to see current hstore in core - It doesn't support
>> nesting, it doesn't support different datatypes, it is not well
>> supported by plpgsql
>>
>
> ... or by many client libraries, though converting hstore values to json
> notation for output usually takes care of that.

The more I look at this, the less comfortable I am moving forward with
hand waving this issue away. The obvious but seemingly all troublesome
options:

-Store things internally using hstore. This seems to require pulling
hstore fully into core, which has this list of issues. Outputting
through a JSON filter seems like a lot of overhead. And even if the
output concerns are addressed, if there's a problem processing the raw
data with PL/pgSQL that would be bad. I didn't think about that at all
until Pavel brought it up.

-Go back to a simpler composite type idea for storing this data. It
feels wrong to create something that looks a lot like hstore data, but
isn't. There's probably subtle display/client/processing issues in
there I haven't thought of too.

-Try to store the data in a JSON friendly way in the first place.

That last one seems to lead right to...

> I can't help but suspect that hstore will be subsumed by native storage
> and indexing of json objects, since these are already widely supported
> in KV or document stores. Of course, that requires that we come to some
> agreement on how to represent literal scalars for interaction with json,
> which hasn't seen much progress.

If this is the Right Way to solve this problem, that's puts a serious
snag in doing something useful with Timing Events in he near future. I
know better than to try and fight against following the correct path
once it's identified. I can't claim any good expertise on client
encoding/transfer issues though; that's not a strong area for me.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Kupershmidt 2012-12-12 01:58:58 Re: Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)
Previous Message Tom Lane 2012-12-12 01:41:23 Re: Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)