Title: database & table size
Hi,
Have you tried to run 'VACUUM FULL' command?
According to PostgreSQL documentation
-8<---
8.2.1. Recovering disk space
In normal PostgreSQL operation, an UPDATE or DELETE of a row does not
immediately remove the old tuple (ver
On Wed, 25 Jun 2003, Anagha Joshi wrote:
> 4. the file '2078989' corresponds to 'cdrrec' file (table)
>
> $ ls -l 2078989
> -rw--- 1 postgres postgres 2359296 Jun 24 17:18 2078989
>
> This means table 'cdrrec' takes approx. 2030.2626953125 KB i.e. approx.
> 2MB
>
> Table is like
Title: database & table size
Hello ,
Here is something I’ve found related to database & table size
My databse name is ’test’ and table name is ‘cdrrec’.
1. Following will give oids & database
test=# select datname, oid from pg_database;
datname | oid
-+-
On Tuesday 24 June 2003 03:15 pm, Rudi Starcevic wrote:
> I'll be using smaller tables with appropriate join tables and PHP.
> Just for interests sake I'll be using Dia to plan the schema.
> I prefer to use the UML drawing tools instead of the ER ones.
Off topic, but if you're using KDE you might
Josh, Jonathan ..
Thanks for your replies.
You mail was exactly what I was hoping for - your best practise opinion.
I do have a grasp of the theory involved with SQL but your input on
those 'other' constraints like time, language, longevity etc was just
what I was interested in.
I'll be using sm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 23 June 2003 22:19, Rudi Starcevic wrote:
> I"m not sure whether to have on larger table or 2 smaller one with a
> join table.
Theory says you are better off with the join tables. Practical reality agrees
with this. It takes a bit more work
Rudi,
> For this task, a searchable directory, which design would be better.
> In know the second is more flexible as new features can be added but I
> have very limited time and
> I think the one larger table design would be quicker to build.
Sounds like you already have a clear grasp of the sit
Dnia 2003-06-24 00:04, Użytkownik Tomasz Myrta napisał:
select package_name,
count(*) as n_packages
from
packages
join package_log using (package_id);
And one more:
select package_name,
sum(case when package_log.package_id is not null then 1 else 0 end)
as n_packages
from
packages
left
On Mon, 23 Jun 2003 13:59:52 -0500 (CDT)
"Ryan" <[EMAIL PROTECTED]> wrote:
> package_id | integer | not null default
> I must be a total space case today because I can't hammer out the sql to
> get a listing of all the packages with a count() of the package_log by
> package_id.
if you would
