Em 17/09/2012 00:17, Jeff Janes escreveu:
On Tue, Sep 11, 2012 at 9:34 AM, Edson Richter wrote:
No, there is no problem. Just trying to reduce database size forcing these
fields to compress.
Actual database size = 8Gb
Backup size = 1.6Gb (5x smaller)
Seems to me (IMHO) that there is room for i
On Tue, Sep 11, 2012 at 9:34 AM, Edson Richter wrote:
>
> No, there is no problem. Just trying to reduce database size forcing these
> fields to compress.
> Actual database size = 8Gb
> Backup size = 1.6Gb (5x smaller)
>
> Seems to me (IMHO) that there is room for improvement in database storage
>
Em 13/09/2012 16:12, Kevin Grittner escreveu:
Edson Richter wrote:
Anything else I can do from here?
Did that result in more accurate numbers for pg_class.reltuples?
-Kevin
I don't how number were not accurate - for me they always seemed
consistent with what I knew about it...
Let's
Edson Richter wrote:
> Anything else I can do from here?
Did that result in more accurate numbers for pg_class.reltuples?
-Kevin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Em 12/09/2012 21:50, Edson Richter escreveu:
Em 12/09/2012 15:09, Kevin Grittner escreveu:
VACUUM FREEZE VERBOSE ANALYZE
Sorry, most of the messages are in portuguese, but I guess numbers are
more important, right?
INFO: índice "pk_notafiscalarq" agora contém 715084 versões de
registros em
Em 12/09/2012 15:09, Kevin Grittner escreveu:
VACUUM FREEZE VERBOSE ANALYZE
Sorry, most of the messages are in portuguese, but I guess numbers are
more important, right?
INFO: índice "pk_notafiscalarq" agora contém 715084 versões de
registros em 1963 páginas
DETALHE: 0 versões de registros
Edson Richter wrote:
> SELECT pg_size_pretty(pg_database_size('mydatabase'));
> pg_size_pretty
>
> 7234 MB
> SELECT nspname || '.' || relname AS "relation",
> pg_size_pretty(pg_relation_size(C.oid)) AS "size"
>FROM pg_class C
>LEFT JOIN pg_namespace N ON (N.oi
Em 12/09/2012 09:16, Kevin Grittner escreveu:
Edson Richter wrote:
Em 12/09/2012 00:37, Edson Richter escreveu:
Em 11/09/2012 14:59, Kevin Grittner escreveu:
Edson Richter wrote:
[biggest relation was a table heap with 29321 pages]
[block size is 8 KB]
So your biggest table is actual
Edson Richter wrote:
> Em 12/09/2012 00:37, Edson Richter escreveu:
>> Em 11/09/2012 14:59, Kevin Grittner escreveu:
>>> Edson Richter wrote:
[biggest relation was a table heap with 29321 pages]
[block size is 8 KB]
>>> So your biggest table is actually 229 MB. Something is not add
Em 12/09/2012 00:37, Edson Richter
escreveu:
Em 11/09/2012 14:59, Kevin Grittner escreveu:
Edson Richter
wrote:
Em 11/09/2012 14:34, Kevin Grittner
escreveu:
Edson Richter
wrote:
Em 11/09/2012 14:59, Kevin Grittner escreveu:
Edson Richter wrote:
Em 11/09/2012 14:34, Kevin Grittner escreveu:
Edson Richter wrote:
For storage, du -h --max-depth 1 on data directory gives me the
amount of data.
Biggest objects are just the tables with files.
I've 2 tables th
Edson Richter wrote:
> Em 11/09/2012 14:34, Kevin Grittner escreveu:
>> Edson Richter wrote:
>>
>>> For storage, du -h --max-depth 1 on data directory gives me the
>>> amount of data.
>>
>>> Biggest objects are just the tables with files.
>>
>>> I've 2 tables that held all these objects.
Em 11/09/2012 14:34, Kevin Grittner escreveu:
Edson Richter wrote:
For storage, du -h --max-depth 1 on data directory gives me the
amount of data.
Biggest objects are just the tables with files.
I've 2 tables that held all these objects. Structure is
create table MYTABLE (id bigint
Edson Richter wrote:
> For storage, du -h --max-depth 1 on data directory gives me the
> amount of data.
> Biggest objects are just the tables with files.
> I've 2 tables that held all these objects. Structure is
>
> create table MYTABLE (id bigint not null primary key, mimetype
> varchar(
Em 11/09/2012 14:00, Kevin Grittner escreveu:
Edson Richter wrote:
there is no problem. Just trying to reduce database size
Actual database size = 8Gb
Backup size = 1.6Gb (5x smaller)
Seems to me (IMHO) that there is room for improvement in database
storage (we don't have many indexes,
Edson Richter wrote:
> there is no problem. Just trying to reduce database size
> Actual database size = 8Gb
> Backup size = 1.6Gb (5x smaller)
>
> Seems to me (IMHO) that there is room for improvement in database
> storage (we don't have many indexes, and biggest tables are just
> the ones
Em 11/09/2012 09:40, Kevin Grittner escreveu:
Edson Richter wrote:
So, should I use
alter table MYTABLE set storage EXTENDED
Don't bother; that is the default.
This should already be happening automatically. Is there some
problem you're seeing that you want to fix? If so, you shoul
Edson Richter wrote:
> So, should I use
>
> alter table MYTABLE set storage EXTENDED
Don't bother; that is the default.
This should already be happening automatically. Is there some
problem you're seeing that you want to fix? If so, you should
probably describe that.
-Kevin
--
Sent vi
Em 10/09/2012 19:06, Kevin Grittner escreveu:
Edson Richter wrote:
this automatic compression applies to bytea fields?
Yes, but keep in mind that anything which is already compressed or
encrypted will probably not compress much if at all. Many of the
binary objects you might want to sto
Edson Richter wrote:
> this automatic compression applies to bytea fields?
Yes, but keep in mind that anything which is already compressed or
encrypted will probably not compress much if at all. Many of the
binary objects you might want to store in the database probably
already use compressio
Em 10/09/2012 16:09, Edson Richter escreveu:
Em 10/09/2012 15:35, Tom Lane escreveu:
Edson Richter writes:
I would like to know if there is any plan to implement compressed
fields
(just a "flag" in the field definition, like "not null") at database
side (these fields are and will never be ind
Em 10/09/2012 15:35, Tom Lane escreveu:
Edson Richter writes:
I would like to know if there is any plan to implement compressed fields
(just a "flag" in the field definition, like "not null") at database
side (these fields are and will never be indexed neither used for search).
Any field value
Edson Richter writes:
> I would like to know if there is any plan to implement compressed fields
> (just a "flag" in the field definition, like "not null") at database
> side (these fields are and will never be indexed neither used for search).
Any field value over a couple kilobytes is compres
Hi,
My application have few binary fields that accept files. Most of them
are XML files archived for reference only.
I would like to know if there is any plan to implement compressed fields
(just a "flag" in the field definition, like "not null") at database
side (these fields are and will nev
24 matches
Mail list logo
