Em 17/05/2016 11:07, Merlin Moncure escreveu:
> On Mon, Apr 25, 2016 at 8:48 PM, Adam Brusselback
> <adambrusselback@gmail.com> wrote:
>>> It is not difficult to simulate column store in a row store system if
>>> you're willing to decompose your tables into (what is essentially)
>>> BCNF fragments. It simply is laborious for designers and programmers.
>> I could see a true column store having much better performance than tricking
>> a row based system into it. Just think of the per-row overhead we currently
>> have at 28 bytes per row. Breaking up data manually like that may help a
>> little, but if you don't have a very wide table to begin with, it could turn
>> out you save next to nothing by doing so. A column store wouldn't have this
>> issue, and could potentially have much better performance.
> FYI tuple header is 23 bytes, not 28 bytes
> (http://www.postgresql.org/docs/9.5/static/storage-page-layout.html).
> Personally I think column stores are a bit overrated. They are faster
> at certain things (in some cases much faster) but tend to put pretty
> onerous requirements on application design so that they are very much
> a special case vehicle.
>
> merlin
>
>
+1 (to not change current defaults).
I would tend to avoid columnar store "as default" because this would
badly affect hundred of thousands of applications around the world.
Columnar store should have its own niche, but certainly doesn't fit my
needs.
Would you give a "option to change the store" is another history.
As I work with objects at programming side, and ORM works just so well,
it is a really waste of time (and other resources) to change systems
that are working well in the past 10 or more years.
Just my 2c,
Edson Richter