Re: Timing events WIP v1

2012/12/12 Greg Smith <greg(at)2ndquadrant(dot)com>:
> 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.
>

I didn't watch this discussion all time, but I don't understand why
you need a complex datatypes.

Maybe you can do normalization and complex data types can hold only in memory.

Regards

Pavel

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