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
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
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
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
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
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
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
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 =
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
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.
10 matches
Mail list logo
