Re: [PERFORM] How number of columns affects performance

2003-08-01 Thread Francisco J Reyes
On Fri, 1 Aug 2003, Ron Johnson wrote: Do all 100 fields *really* all refer to the same *one* entity, with no repeating values, etc? Yes all fields belong to the same entity. I used 100 as an example it may be something like 60 to 80 fields (there are two tables in question). I don't formally

Re: [PERFORM] How number of columns affects performance

2003-08-01 Thread Ron Johnson
On Fri, 2003-08-01 at 12:14, Francisco J Reyes wrote: On Fri, 1 Aug 2003, Ron Johnson wrote: Do all 100 fields *really* all refer to the same *one* entity, with no repeating values, etc? Yes all fields belong to the same entity. I used 100 as an example it may be something like 60 to 80

Re: [PERFORM] How number of columns affects performance

2003-08-01 Thread Josh Berkus
Francisco, Yes all fields belong to the same entity. I used 100 as an example it may be something like 60 to 80 fields (there are two tables in question). I don't formally do 3rd normal form, but for the most part I do most of the general concepts of normalization. If not, then good design

Re: [PERFORM] How number of columns affects performance

2003-08-01 Thread Ron Johnson
On Fri, 2003-08-01 at 12:44, Josh Berkus wrote: Francisco, Yes all fields belong to the same entity. I used 100 as an example it may be something like 60 to 80 fields (there are two tables in question). I don't formally do 3rd normal form, but for the most part I do most of the general

Re: [PERFORM] How number of columns affects performance

2003-08-01 Thread Josh Berkus
Ron, You snipped out too much, because that's exactly what I said... Another way of writing it: only split the table if some of the fields are not unitary to the entity. Sorry! No offense meant. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of

Re: [PERFORM] How number of columns affects performance

2003-08-01 Thread Francisco J Reyes
On Fri, 1 Aug 2003, Josh Berkus wrote: My attitude toward these normalization vs. performance issues is consistenly the same: First, verify that you have a problem. That is, build the database with everything in one table (or with child tables for Nullable fields, as above) and try to run

[PERFORM] I can't wait too much: Total runtime 432478.44 msec

2003-08-01 Thread Fernando Papa
Title: Mensaje Hi all! Really I don't know what happened with this query. I'm running PG 7.3.1 on solaris, vaccumed (full) every nigth. The cardinality of each table was: cont_contenido: 97 rows juegos_config: 40 rows cont_publicacion: 446 rows not huge tables... however, this query

Re: [PERFORM] How number of columns affects performance

2003-08-01 Thread Josh Berkus
Francisco, I think I understand your point, however it would be very laborious after you do all development to find out you need to de-normalize. Not terribly. Views and Rules are good for this. On your experience at which point it would actually help to do this de-normalization in

Re: [PERFORM] I can't wait too much: Total runtime 432478.44 msec

2003-08-01 Thread Christopher Browne
I'd point at the following as being a sterling candidate for being a cause of this being slow...  AND cont_publicacion.fecha_publicacion = (SELECT max(cp1.fecha_publicacion)   FROM cont_publicacion cp1    WHERE cp1.id_instalacion =

Re: [PERFORM] I can't wait too much: Total runtime 432478.44 msec

2003-08-01 Thread Josh Berkus
Fernando, AND cont_publicacion.fecha_publicacion = (SELECT max(cp1.fecha_publicacion) FROM cont_publicacion cp1 WHERE cp1.id_instalacion = cont_publicacion.id_instalacion AND cp1.id_contenido = cont_publicacion.id_contenido

Re: [PERFORM] OSDL Database Test Suite 3 is available on PostgreSQL

2003-08-01 Thread Josh Berkus
Jenny, OSDL has ported OSDL Database Test Suite 3(OSDL-DBT3) to PostgreSQL. It drives the database with an ad-hoc decision support workload. It helps database developers and users to identify database performance issues. Way, way, cool! We've been waiting for something like this eagerly.