Thread: pgsql: Extend cube on-disk format to pack points more tightly.

pgsql: Extend cube on-disk format to pack points more tightly.

From
Heikki Linnakangas
Date:
Extend cube on-disk format to pack points more tightly.

If the lower left and upper right corners of a cube are the same, set a
flag in the cube header, and only store one copy of the coordinates. That
cuts the on-disk size into half for the common case that the cube datatype
is used to represent points rather than boxes.

The new format is backwards-compatible with the old one, so pg_upgrade
still works. However, to get the space savings, the data needs to be
rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old
Datums will just be moved to the new heap/index as is. A pg_dump and
reload, or something similar like casting to text and back, will do the
trick.

This patch deliberately doesn't update all the alternative expected output
files, as I don't have access to machines that produce those outputs. I'm
not sure if they are still relevant, but if they are, the buildfarm will
tell us and produce the diff required to fix it. If none of the buildfarm
animals need them, they should be removed altogether.

Patch by Stas Kelvich.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/08612f45a0e236bd01db3fc96cc1fa7bfabc927c

Modified Files
--------------
contrib/cube/cube.c              |  483 +++++++++++++++++++++++---------------
contrib/cube/cubedata.h          |   39 ++-
contrib/cube/cubeparse.y         |   69 ++++--
contrib/cube/expected/cube_1.out |  281 ++++++++++++++++++++++
contrib/cube/expected/cube_2.out |  281 ++++++++++++++++++++++
contrib/cube/sql/cube.sql        |   59 +++++
6 files changed, 990 insertions(+), 222 deletions(-)


Re: pgsql: Extend cube on-disk format to pack points more tightly.

From
Tom Lane
Date:
Heikki Linnakangas <heikki.linnakangas@iki.fi> writes:
> This patch deliberately doesn't update all the alternative expected output
> files, as I don't have access to machines that produce those outputs. I'm
> not sure if they are still relevant, but if they are, the buildfarm will
> tell us and produce the diff required to fix it. If none of the buildfarm
> animals need them, they should be removed altogether.

dugong, for one, doesn't like this patch.

My usual habit for fixing alternative expected files is to apply the same
diff to those files as I got for the one my machine produces.  While this
occasionally doesn't work (when there are changes in the unportable
results as well as the portable ones), it works 90% of the time, whereas
your approach here works zero percent of the time.

            regards, tom lane