Re: Timing events WIP v1 - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Timing events WIP v1
Date
Msg-id 50C7E142.7030605@2ndQuadrant.com
Whole thread Raw
In response to Re: Timing events WIP v1  (Craig Ringer <craig@2ndQuadrant.com>)
Responses Re: Timing events WIP v1
List 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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)
Next
From: Josh Kupershmidt
Date:
Subject: Re: Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)