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(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org