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
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) |