Re: [SQL]

2010-07-06 Thread Justin Graf
I wrote an article covering this on the wiki

http://wiki.postgresql.org/wiki/BinaryFilesInDB

I need to update to for 9.0  as bytea now allows HEX format strings

http://developer.postgresql.org/pgdocs/postgres/datatype-binary.html








All legitimate Magwerks Corporation quotations are sent in a .PDF file 
attachment with a unique ID number generated by our proprietary quotation 
system. Quotations received via any other form of communication will not be 
honored.

CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally 
privileged, confidential or other information proprietary to Magwerks 
Corporation and is intended solely for the use of the individual to whom it 
addresses. If the reader of this e-mail is not the intended recipient or 
authorized agent, the reader is hereby notified that any unauthorized viewing, 
dissemination, distribution or copying of this e-mail is strictly prohibited. 
If you have received this e-mail in error, please notify the sender by replying 
to this message and destroy all occurrences of this e-mail immediately.
Thank you.
<>
-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql


[SQL] How To Calculate Table Size Minus Deleted Rows

2010-07-06 Thread Brian Helm
I'm in the need of a way to determine the disk size of a table that
excludes dead tuples.  Here is my situation.  Our company would like to
provide a "rolling storage" solution on a per schema basis.  So
basically we set a "quota" of the amount of disk space that a schema can
occupy.  Every night a cron job is run that calculates the overage of
each schema's quota and deletes as many rows as necessary from each
table to bring the schema back within quota limits.

I was trying to use pg_total_relation_size to calculate the amount of
space consumed by each table, but I quickly learned that even after
deleting/vacuuming, the reported size of the table does not drop.  I
assume this is due to the nature of how a lazy vacuum works.  Is there a
way to get the size of the table that excludes the freed (but not
released) space from a delete/vacuum run?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Brian Helm
Security Confidence Corporation
brian.h...@securityconfidence.com
513.388-4500/866.732.2661 Ext 106
www.SecurityConfidence.com


-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql


Re: [SQL]

2010-07-06 Thread silly sad
On 07/06/10 21:52, Justin Graf wrote:
> I wrote an article covering this on the wiki
> 
> http://wiki.postgresql.org/wiki/BinaryFilesInDB

there are some "red flags" in communication
(particularly reading papers)
one of them is "binary data" which ITSELF IS NONSENCE.

-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql