Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] Postmaster getting veeeery big

From: Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il>
To: eg(at)tzv(dot)fal(dot)de, pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] Postmaster getting veeeery big
Date: 1999-05-19 14:40:42
Message-ID: l03130304b3687a4f6aa7@[147.233.159.109] (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-interfaces
At 12:05 +0300 on 18/05/1999, Eildert Groeneveld wrote:


>
> Hello everyone,
> we observe a problem when doing some sort of aggregation like
>
> select distinct count(substr(narodene,5,4)) from raw_field;
>
> (raw_field has 1300000 rows)
>
>
> On executing this query the postmaster grows in memory size until it runs
> out of virtual mem and dies.
>
> Any ideas of what is going on and how to avoid this?

No matter what the memory problem is (memory used for the substr function
not released, probably), I think your query is wrong.

I think what you wanted was the count of the distinct substrings. But
that's "count distinct" (which is not implemented in PostgreSQL yet) and
not "distinct count". Distinct count only has meaning in a group-by query.

So you should probably rephrase your query as:

SELECT count(*)
FROM raw_field r1
WHERE int4( r1.oid ) = (
   SELECT max( in4(oid) )
   FROM raw_field r2
   WHERE substr( r1.narodene,5,4) = substr( r2.narodene,5,4)
);

The WHERE clause will only become true when the current row has the maximal
oid for the same substring of narodene. In effect, it selects one row for
each substring. Thus you will get the count of the distinct substrings.

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma



In response to

pgsql-interfaces by date

Next:From: Eildert GroeneveldDate: 1999-05-19 19:35:26
Subject: Postmaster getting veeeery big: SUBSTR bug
Previous:From: selkovjrDate: 1999-05-19 13:57:13
Subject: Re: [INTERFACES] Paths in DBD::Pg

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group