Re: Timing events WIP v1
От | Greg Smith |
---|---|
Тема | Re: Timing events WIP v1 |
Дата | |
Msg-id | 50C7E142.7030605@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: Timing events WIP v1 (Craig Ringer <craig@2ndQuadrant.com>) |
Ответы |
Re: Timing events WIP v1
|
Список | 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 по дате отправления: