From: | Greg Spiegelberg <gspiegelberg(at)cranel(dot)com> |
---|---|
To: | Dror Matalon <dror(at)zapatec(dot)com> |
Cc: | PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Compare rows |
Date: | 2003-10-08 19:07:30 |
Message-ID: | 3F846072.3090700@cranel.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Dror,
I gave this some serious thought at first. I only deal with
int8, numeric(24,12) and varchar(32) columns which I could
reduce to 3 different tables. Problem was going from 1700-3000
rows to around 300,000-1,000,000 rows per system per day that
is sending data to our database.
BTW, the int8 and numeric(24,12) are for future expansion.
I hate limits.
Greg
Dror Matalon wrote:
> It's still not quite clear what you're trying to do. Many people's gut
> reaction is that you're doing something strange with so many columns in
> a table.
>
> Using your example, a different approach might be to do this instead:
>
> Day | Name | Value
> ------+-------------+-----------
> Oct 1 | OS | Solaris 5.8
> Oct 1 | Patch | 108528-12
> Oct 3 | Patch | 108528-13
>
>
> You end up with lots more rows, fewer columns, but it might be
> harder to query the table. On the other hand, queries should run quite
> fast, since it's a much more "normal" table.
>
> But without knowing more, and seeing what the other columns look like,
> it's hard to tell.
>
> Dror
--
Greg Spiegelberg
Sr. Product Development Engineer
Cranel, Incorporated.
Phone: 614.318.4314
Fax: 614.431.8388
Email: gspiegelberg(at)Cranel(dot)com
Cranel. Technology. Integrity. Focus.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Spiegelberg | 2003-10-08 19:10:53 | Re: Compare rows |
Previous Message | Dror Matalon | 2003-10-08 18:55:27 | Re: Compare rows |