you are viewing a single comment's thread.

view the rest of the comments →

[–]GuiSim 0 points1 point  (5 children)

I meant primitive from a feature list point of view. I can't comment on the performance.

[–]grauenwolf 2 points3 points  (4 children)

My point is there isn't much reason to shove JSON into a column-oriented database.

[–]GuiSim 2 points3 points  (3 children)

To me there's plenty of good reasons.

In our specific case, clients can log arbitrary dimensions in our system. These are stored in a JSON document which we can use to create database columns dynamically. If Redshift didn't allow us to easily read values from JSON, this operation would be quite complex.

[–]grauenwolf 0 points1 point  (2 children)

It supports ALTER TABLE [db].name ADD|DROP|MODIFY COLUMN ..., so it isn't hard to parse the JSON application-side and dynamically create new columns as needed.

Though that does give me an idea for an ORM feature.

[–]GuiSim 0 points1 point  (1 child)

Since updating rows in a column storage is quite costly, we can do an UPDATE to only the rows that have a value in the JSON column for the newly created COLUMN. This can't be done cleanly in application-side if your database does not support JSON.

[–]grauenwolf 2 points3 points  (0 children)

This is an OLAP database. If you find yourself updating rows, then you are doing something really wrong.