Guten Tag Thorsten Schöning,
am Mittwoch, 10. Februar 2021 um 09:58 schrieben Sie:
>> unpartitioned: 6,4 GiB
>> half-yearly parts: 4,8 GiB
>> yearly parts: 4,8 GiB
The above number for `unpartitioned` might be wrong: I've re-created
the same database, applied the same data migration like
Thorsten:
On Wed, Feb 10, 2021 at 12:46 PM Thorsten Schöning
wrote:
UUppzz, completely missed the second message.
> > CREATE INDEX idx_datagram_for_time_window ON datagram USING btree
> > (src_meter, captured_at DESC);
Depending on the query and data "shape", this may be chosen or not for
Thorsten:
On Wed, Feb 10, 2021 at 12:36 PM Thorsten Schöning
wrote:
> Guten Tag Francisco Olarte,
> am Mittwoch, 10. Februar 2021 um 10:38 schrieben Sie:
> > [...]and partitioning sorts partially
> > by date ( or fully if you have made the partitions by range-querying
> > via index scan ).[...]
>
Guten Tag Francisco Olarte,
am Mittwoch, 10. Februar 2021 um 10:38 schrieben Sie:
> [...]and partitioning sorts partially
> by date ( or fully if you have made the partitions by range-querying
> via index scan ).[...]
That statement is especially interesting not only because of my
dump-size, but
Guten Tag Francisco Olarte,
am Mittwoch, 10. Februar 2021 um 10:38 schrieben Sie:
> [...]and partitioning sorts partially
> by date ( or fully if you have made the partitions by range-querying
> via index scan ).[...]
That statement is especially interesting not only because of my
dump-size, but
Thorsten:
On Wed, Feb 10, 2021 at 9:58 AM Thorsten Schöning wrote:
...
> I've changed the new table "datagram" to be a partitioned one with
> partitions containing rows per year and per half-year. Each partition
> contains far less rows than before this way and while I only tested
> with "--compr
Guten Tag Thorsten Schöning,
am Dienstag, 9. Februar 2021 um 10:56 schrieben Sie:
> Any explanation for the increased dump size? Thanks!
While I don't have a detailed explanation myself, there's the
following hint [in the docs][1]:
> For the custom archive format, this specifies compression of
Guten Tag Thorsten Schöning,
am Dienstag, 9. Februar 2021 um 10:56 schrieben Sie:
> Any explanation for the increased dump size? Thanks!
Some more data:
> --compress=0: 20 vs. 25 GiB
> --compress=DEFAULT: 6,5 vs. 5,6 GiB
> --compress=9: 6,4 vs. 5,5 GiB
From the docs:
> For the cus
=?utf-8?B?VGhvcnN0ZW4gU2Now7ZuaW5n?= writes:
> for various reasons I've migrated my database schema from 4 tables
> with some additional indexes to keep integrity and stuff to 1 table
> only. That made some of the former used indexes obsolete and resulted
> in overall less consumed storage:
> The o
