Hi all,
this should be trivial, but if I dump and restore the very same
database the restored one is bigger than the original one.
I did vacuumed the database foo, then dumped and restored into bar,
and the latter, even when vacuumed, remains bigger then the original
one.
No other activity was
On Mon, Jul 15, 2019 at 7:21 PM Peter Geoghegan wrote:
> Sometimes B-Tree indexes can be *larger* after a REINDEX (or after
> they're recreated with a CREATE INDEX). It's not that common, but it
> does happen. There isn't actually a very large size difference here,
> so it seems worth comparing in
On Mon, Jul 15, 2019 at 7:07 PM Adrian Klaver wrote:
> What does \l+ show?
The same as pg_size_pretty:
foo=# \l+
List of databases
Name| Owner | Encoding | Collate | Ctype | Access
privileges | Size | Tablespace |
On Mon, Jul 15, 2019 at 6:22 AM Luca Ferrari wrote:
> What am I missing here?
Sometimes B-Tree indexes can be *larger* after a REINDEX (or after
they're recreated with a CREATE INDEX). It's not that common, but it
does happen. There isn't actually a very large size difference here,
so it seems wo
On 7/15/19 6:21 AM, Luca Ferrari wrote:
Hi all,
this should be trivial, but if I dump and restore the very same
database the restored one is bigger than the original one.
I did vacuumed the database foo, then dumped and restored into bar,
and the latter, even when vacuumed, remains bigger then th
Hi all,
this should be trivial, but if I dump and restore the very same
database the restored one is bigger than the original one.
I did vacuumed the database foo, then dumped and restored into bar,
and the latter, even when vacuumed, remains bigger then the original
one.
No other activity was runn
