suggestion. I think this will not help us to differentiate
> between live tuples, dead tuples and free space.
>
>
>
> Best regards,
>
> Manuel
>
>
>
> *From:* Torsten Förtsch
> *Sent:* 15 July 2024 18:59
> *To:* Shenavai, Manuel
> *Cc:* pgsql-genera
Thanks for the suggestion. I think this will not help us to differentiate
between live tuples, dead tuples and free space.
Best regards,
Manuel
From: Torsten Förtsch
Sent: 15 July 2024 18:59
To: Shenavai, Manuel
Cc: pgsql-general@lists.postgresql.org
Subject: Re: Monitoring DB size
Slightly
: Shenavai, Manuel
Cc: pgsql-general@lists.postgresql.org
Subject: Re: Monitoring DB size
You don't often get email from
imtia...@bitnine.net<mailto:imtia...@bitnine.net>. Learn why this is
important<https://aka.ms/LearnAboutSenderIdentification>
Hi,
You can choose from the
| 4
pg_wal | 16392
pg_xact |12
postgresql.auto.conf | 4
postmaster.opts | 4
postmaster.pid | 4
(21 rows)
Time: 0.282 ms
On Mon, Jul 15, 2024 at 4:42 PM Shenavai, Manuel
wrote:
> Hi everyone,
>
>
>
> we currently capture the db
Hi,
You can choose from the following options. Hopefully, they will meet your
requirements
1) pg_stat_user_tables view
2) pgstattuple extension
Regards,
Muhammad imtiaz
On Mon, 15 Jul 2024, 19:42 Shenavai, Manuel,
wrote:
> Hi everyone,
>
>
>
> we currently capt
Hi everyone,
we currently capture the db size (pg_database_size) which gives the “Disk space
used by the database with the specified name”. Is it possible to further split
this data how much space is occupied by live tuples, dead tuples and free space?
We would like to have something like:
DB
On Thu, 2023-11-16 at 14:49 +0800, Eric Wong wrote:
> We discovered a disk usage difference between our primary and standby node.
>
> After much investigation, the disk usage difference is caused by some
> extra files within the database directory 16432. The extra files are
> only found on the st
Hi postgres guru out there:
We discovered a disk usage difference between our primary and standby node.
After much investigation, the disk usage difference is caused by some
extra files within the database directory 16432. The extra files are
only found on the standby node, not present on the pr
- Mensagem original -
> De: "Magnus Hagander"
> Para: "Laurenz Albe"
> Cc: "Alvaro Herrera" , "luis.roberto"
> , "pgsql-general"
>
> Enviadas: Terça-feira, 27 de abril de 2021 4:05:42
> Assunto: Re: DB size
On Tue, Apr 27, 2021 at 8:59 AM Laurenz Albe wrote:
>
> On Mon, 2021-04-26 at 16:45 -0400, Alvaro Herrera wrote:
> > I would guess that there are leftover files because of those crashes you
> > mentioned. You can probably look for files in the database subdir in
> > the data directory that do not
On Mon, 2021-04-26 at 16:45 -0400, Alvaro Herrera wrote:
> I would guess that there are leftover files because of those crashes you
> mentioned. You can probably look for files in the database subdir in
> the data directory that do not appear in the pg_class.relfilenode
> listing for the database.
Hi,
Le lun. 26 avr. 2021 à 22:59, a écrit :
>
> - Mensagem original -
> > De: "Alvaro Herrera"
> > Para: "luis.roberto"
> > Cc: "pgsql-general"
> > Enviadas: Segunda-feira, 26 de abril de 2021 17:45:34
> > Assunto: Re:
- Mensagem original -
> De: "Alvaro Herrera"
> Para: "luis.roberto"
> Cc: "pgsql-general"
> Enviadas: Segunda-feira, 26 de abril de 2021 17:45:34
> Assunto: Re: DB size
> I would guess that there are leftover files because of those cr
- Mensagem original -
> De: "Josef Šimánek"
> Para: "luis.roberto"
> Cc: "pgsql-general"
> Enviadas: Segunda-feira, 26 de abril de 2021 17:40:05
> Assunto: Re: DB size
> Do you have any indexes in mydb database?
Yes, I do. I believe
On 2021-Apr-26, luis.robe...@siscobra.com.br wrote:
> SELECT sum(pg_total_relation_size(relid)),
> pg_size_pretty(sum(pg_total_relation_size(relid)))
> FROM pg_catalog.pg_stat_all_tables
>
>
> sum |pg_size_pretty|
> +--+
> 518549716992|483 GB
po 26. 4. 2021 v 22:25 odesílatel napsal:
>
> Hi!
>
> I've looked around, but could only find very old answers to this question,
> and maybe it changed since then...
>
> I'm struggling to identify the cause of the difference in size between the
> sum of all relations (via pg_total_relation_size
Hi!
I've looked around, but could only find very old answers to this question, and
maybe it changed since then...
I'm struggling to identify the cause of the difference in size between the sum
of all relations (via pg_total_relation_size) and pg_database_size:
SELECT sum(pg_total_relation_s
On Wed, Jul 17, 2019 at 7:33 PM Sonam Sharma wrote:
>
> I took the backup using pg_dump with gzip option and restored it with psql.
It does not change the way you backed up, chances are when you
restored it the database cropped table and index bloating as already
mentioned.
The other, remote chan
I took the backup using pg_dump with gzip option and restored it with psql.
On Wed, Jul 17, 2019, 10:39 PM David G. Johnston
wrote:
> On Wed, Jul 17, 2019 at 10:03 AM Sonam Sharma
> wrote:
>
>> I have restored database and the db size of source was around 55gb and
>> afte
temp objects or queries using temp files would
have cleared and hence reclaimed disk.
If none of these are true, then I guess experts would pitch in.
On Wed, 17 Jul 2019 at 10:33 PM Sonam Sharma wrote:
> I have restored database and the db size of source was around 55gb and
> after restore
On Wed, Jul 17, 2019 at 10:03 AM Sonam Sharma wrote:
> I have restored database and the db size of source was around 55gb and
> after restore the db size of Target is 47gb.
>
You haven't described how you restored the database but measuring size
doesn't work because typicall
I have restored database and the db size of source was around 55gb and
after restore the db size of Target is 47gb.
How to confirm if restore was successful or not ?
The table count is also same.
On Wed, Oct 3, 2018 at 2:59 PM Sonam Sharma wrote:
>
>
> On Wed, Oct 3, 2018 at 6:21 PM Sonam Sharma wrote:
>
>> Hello Ben,
>>
>> When we do \l+ , it is different than source, when we load backup from
>> target server.
>>
>Backup is taken using pg_dump and its loaded as psql db name
>
It'
On Wed, Oct 3, 2018 at 6:21 PM Sonam Sharma wrote:
> Hello Ben,
>
> When we do \l+ , it is different than source, when we load backup from
> target server.
>
Backup is taken using pg_dump and its loaded as psql db name
>
> Regards,
>
> Sonam
>
>
>
>
>
>
> On Wed, Oct 3, 2018 at 6:17 PM Benj
Hi Sonam,
it is common that after an export (pg_dump) and a consecutive import, the new
database uses less space than the old one.
Under some circumstances, indexes can become unbalancedor bloated, and tables
bloated. And that uses more space than it should.
for the sake of trying it out: If y
Hello Ben,
When we do \l+ , it is different than source, when we load backup from
target server
Regards,
Sonam
On Wed, Oct 3, 2018 at 6:17 PM Benjamin Scherrey
wrote:
> If you're talking about space on drive then you can expect the new one to
> be smaller generally as it has been straig
If you're talking about space on drive then you can expect the new one to
be smaller generally as it has been straight efficient writes rather than a
bunch of updates and deletes which create "holes" in the physical file
space.
It helps if you are more detailed as to what you've observed if you wa
I have restored the database from backup dump but the size of source and
target databases are different. What can be the reason for this ?
Regards,
Sonam
On Mon, Jun 25, 2018 at 1:21 PM, Vikas Sharma wrote:
> Hi All,
>
> I am looking for advice in a issue where two materialized views are being
> refreshed concurrently and dbsize has grown to 150gb from 4gb in two days.
>
> We use two materialized views to keep processed data for faster query
> res
nged mv refresh to concurrently to take advantage of simultaneous
> access when mv refreshed. Now the refresh takes slightly longer and but DB
> size has grown exponentially.
> >
> > I ran full vacuum on DB and size again reduced to 4gb from 150gb.
>
> You did not disable
ery results
> for a search function. Earlier materialized views were refreshed not
> concurrently and all was good on DB.
>
> We changed mv refresh to concurrently to take advantage of simultaneous
> access when mv refreshed. Now the refresh takes slightly longer and but DB
>
refreshed
not concurrently and all was good on DB.
We changed mv refresh to concurrently to take advantage of simultaneous
access when mv refreshed. Now the refresh takes slightly longer and but DB
size has grown exponentially.
I ran full vacuum on DB and size again reduced to 4gb from 150gb.
We need
32 matches
Mail list logo
