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
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
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
-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
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
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
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 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
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
