Re: [HACKERS] UdmSearch: tables vs indices ...

On Thu, 6 Jan 2000, Vince Vielhaber wrote:

> On Thu, 6 Jan 2000, The Hermit Hacker wrote:
> 
> > 
> > We've almost got UdmSearch up and running, and I'm noticing something odd:
> > 
> > -rw-------  1 pgsql  pgsql   204800 Jan  6 00:05 url
> > -rw-------  1 pgsql  pgsql  1622016 Jan  6 00:05 word_url
> 
> Here's what I have on the test system I'm working with.  The apache
> docs are the only thing in it (or that should be in it).
> 
> -rw-------   1 postgres  postgres  1671168 Dec 15 08:35 url
> -rw-------   1 postgres  postgres   278528 Dec 15 08:35 url_crc
> -rw-------   1 postgres  postgres   106496 Dec 15 08:35 url_pkey
> -rw-------   1 postgres  postgres   335872 Dec 15 08:35 url_url
> -rw-------   1 postgres  postgres  1179648 Dec 15 08:35 word_url

Here is *just* http://www.postgresql.org/docs:

-rw-------  1 pgsql  pgsql   3039232 Jan  6 06:02 url
-rw-------  1 pgsql  pgsql  35602432 Jan  6 06:02 dict
-rw-------  1 pgsql  pgsql    303104 Jan  6 06:02 url_pkey
-rw-------  1 pgsql  pgsql    376832 Jan  6 06:02 url_crc
-rw-------  1 pgsql  pgsql   1294336 Jan  6 06:02 url_url
-rw-------  1 pgsql  pgsql  27385856 Jan  6 06:02 word_url
-rw-------  1 pgsql  pgsql      8192 Jan  6 06:01 next_url_id

They are generating what I think is a very very weird looking query on the
tables that appears to be just hanging the whole thing...can someone
explain to me what *this* would do:
    sum(case dict.word when '$t' then 1 else 0 end)

I'm trying to get more details out of Alexander, since I'm guessing that
the query itself could possibly be done cleaner, but they acknowledge that
their PostgreSQL knowledge tends to be rather "sparse", at best :)

More as it becomes available ...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org