Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1

Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>

From: Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>
To: tgl@sss.pgh.pa.us (Tom Lane)
Cc: fpscha@via-net-works.net.ar, pgsql-hackers@postgreSQL.org
Date: 1999-10-23T18:25:25Z
Lists: pgsql-hackers
En un mensaje anterior, Tom Lane escribió:
> It's still convinced it's only going to get one row out of usuarios.
> Weird.  I assume that your 'activa' field is 'bool'?  I've been trying
> to duplicate this misbehavior here, and as near as I can tell the system
> handles selectivity estimates for boolean fields just fine.  Whatever
> percentage of 't' values was seen by the last VACUUM ANALYZE is exactly
> what it uses.
> 
> I am using 6.5.2 and current sources, though, and in your original
> message you said you were on 6.5.0.  If that's right, seems like the
> first thing to try is for you to update to 6.5.2, run another VACUUM
> ANALYZE, and then see if you still get the same bogus row estimates.

I was using 6.5.0 on my first post, then I upgraded and all the vacuum 
and explain commands where from 6.5.2.  Here is my complete database 
definition:


CREATE TABLE usuarios
	(id_usr serial,
	razon_social text NOT NULL,
	nombre_cuenta text NOT NULL,
	grupo int2 NOT NULL, 
	perfil int2 NOT NULL, 
	estado char(1) NOT NULL DEFAULT 'H' CHECK ((estado='H') or (estado='D')), 
	id_madre int4 NOT NULL,
	fecha_creacion datetime DEFAULT CURRENT_DATE,
	fecha_baja datetime,
	gratuita bool DEFAULT 'f',
	activa bool DEFAULT 't',
	observaciones text
	) \g

CREATE TABLE passwd
	(id_usr serial,
	clave_plana text NOT NULL, 
	clave_cifrada text NOT NULL
	) \g

CREATE TABLE perfiles
	(id_perfil serial,
	nombre text NOT NULL,
	descripcion text
	) \g

CREATE TABLE grupos
	(id_grupo serial,
	nombre text NOT NULL,
	descripcion text
	) \g

CREATE TABLE cronometradas
	(id_usr serial,
	fecha_comienzo_cronometrado datetime DEFAULT CURRENT_DATE,
	tipo_cronometrado int2,
	max_segs_vida int4, 
	max_segs_consumo int4
	) \g

CREATE TABLE tipos_cronometrado
	(id_tipo_cronometrado serial,
	nombre text NOT NULL,
	descripcion text
	) \g


> 
> The other odd thing about the above plan is that it's doing an
> explicit sort on perfiles.  Didn't you say that you had an index on
> perfiles.id_perfil?  It should be scanning that instead of doing

It should, as it is serial. What does it mean when PgAccess says a table 
doesn't has a primary key? Would it impact?

Again, thanks!



Fernando P. Schapachnik
Administración de la red
VIA Net Works Argentina SA
Diagonal Roque Sáenz Peña 971, 4º y 5º piso.
1035 - Capital Federal, Argentina. 
(54-11) 4323-3333
http://www.via-net-works.net.ar