Column Tetris Automatisation

Hi

2017-01-15 10:58 GMT+01:00 Nicolas Paris <niparisco@gmail.com>:

Hello,

In postgresl order of columns does have an non negligeable impact on table
size[1].
Table are in many cases dynamic, and new fields can appear in the database
life.
I suspect re-ordering columns based on types would be an automatisable
task would be feaseable such:

```
reorderTableWithTetrisAlgo(table)
return reordered_table
```

Moreover, most client code should not be dependent on column order. Then a
TETRIS option
in VACUUM FULL would be usefull for many users.

lot of applications depends on column order - so this option is pretty
dangerous.

Regards

Pavel

|From: Nicolas Paris
|Hello,
|In postgresl order of columns does have an non negligeable impact on table
|size[1].
|Table are in many cases dynamic, and new fields can appear in the database
life.
|I suspect re-ordering columns based on types would be an automatisable task
|
|Moreover, most client code should not be dependent on column order. Then a
|TETRIS option in VACUUM FULL would be usefull for many users.
|Does that makes sense ?

For me it doesn't. As a database architect/engineer, I always create a data
model first (using some software like Xcase, Embarcadero, Erwin), then use
that software to generate the DDL to create the physical database objects,
then start creating stored functions against those objects.

Since my code follows my model, and since I don't use "select *", and since
I prefer to have all of my identifiers at the "top" of a table, order does
matter...it all ties together nicely, making it easier for other developers
to follow an identical pattern across all of the database objects.

All of that said, the notion of embedding Tetris functionality into a
codebase makes me smile, for some reason...

Mike Sofen

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

I for one would love having something like this available. I also know
i've seen discussed in the past, divorcing the physical column order from
the logical column order, which seems like it'd be useful here as well to
not break the workflow of those who do use ordinal positions for columns.