3 ms·

Yup. Nested hstore and JSON are going to be semantically equivalent ("cast" works both ways), and PgREST will support them equally once 9.4 is released. PgREST

by audreyt 13y ago

Yup. Nested hstore and JSON are going to be semantically equivalent ("cast" works both ways), and PgREST will support them equally once 9.4 is released. PgREST also comes with a shim JSON type for Postgres version 9.1 and earlier, so the column type implementation is mostly hidden from the user.

JonnieCache 13y ago
But hstore will be faster/better because it's a binary representation, right?
- audreyt 13y ago
  Very likely so for the majority of use cases, yes.
- qooleot 13y ago
  JSON will be getting binary representation. Its just a matter of organizing sponsorship of the project.
  - JonnieCache 13y ago
    I assumed everyone would be encouraged to just convert their json columns to hstore if they wanted the extra speed, being as theyre equivalent. What would be the reason for funding JSON-as-binary?
    - rpedela 13y ago
      For better or worse, JSON is becoming a major format and it is a first-order Postgres data type. You need to add the hstore extension if you want it. So it makes sense for people needing/wanting JSON and are not aware of some extension called hstore. In other words, it is about improving the ease of use.
    - stopthemadness 13y ago
      Traditional databases use complicated indexing and storage structures in part to minimize the need to examine unrelated data. hstore is better than plain text for JSON but a scheme closer to the existing PostgreSQL table/page/row/value hierarchy could be better still. I'd recommend reading the recent post https://news.ycombinator.com/item?id=6813937 https://news.ycombinator.com/item?id=6813937
      - JonnieCache 13y ago
        Of course if I need it to be eye-wateringly fast I wouldn't be using a document store. I'd use good old relational or something like redis. Often though you just need a sensible place to put some unimportant schemaless key-value data without a half dozen extra dynamically created tables or whatever. EAV makes me very sad.

by audreyt 13y ago

JonnieCache 13y ago

But hstore will be faster/better because it's a binary representation, right?

audreyt 13y ago
Very likely so for the majority of use cases, yes.
qooleot 13y ago
JSON will be getting binary representation. Its just a matter of organizing sponsorship of the project.
- JonnieCache 13y ago
  I assumed everyone would be encouraged to just convert their json columns to hstore if they wanted the extra speed, being as theyre equivalent. What would be the reason for funding JSON-as-binary?
  - rpedela 13y ago
    For better or worse, JSON is becoming a major format and it is a first-order Postgres data type. You need to add the hstore extension if you want it. So it makes sense for people needing/wanting JSON and are not aware of some extension called hstore. In other words, it is about improving the ease of use.
  - stopthemadness 13y ago
    Traditional databases use complicated indexing and storage structures in part to minimize the need to examine unrelated data. hstore is better than plain text for JSON but a scheme closer to the existing PostgreSQL table/page/row/value hierarchy could be better still. I'd recommend reading the recent post https://news.ycombinator.com/item?id=6813937 https://news.ycombinator.com/item?id=6813937
    - JonnieCache 13y ago
      Of course if I need it to be eye-wateringly fast I wouldn't be using a document store. I'd use good old relational or something like redis. Often though you just need a sensible place to put some unimportant schemaless key-value data without a half dozen extra dynamically created tables or whatever. EAV makes me very sad.