Re: That killer 3rd join...

From: Oliver Smith <oliver(at)ourshack(dot)com>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: That killer 3rd join...
Date: 2000-09-07 00:11:10
Message-ID: 20000907011110.A31180@kfs.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> OTOH, I'm not 100% sure what you're trying to get out
> from this query, I'd have expected that it would be, using
> these metals on this stone gives you this result, but since
> the types of jewelery I get are different on the same row
> of output, I'm a little confused.

Each stone gives a specific set of attributes, but combining it with
silver & plat gives one type of jewellery, while gold & electrum
produce a different type.

The reason for including this is so that a chart can be produced
which shows what attributes each stone modifies, how much those
attributes are modified for each stone+metal combo, and what type
of jewellery is produced in the combo.

See http://www.kfs.org/~oliver/eq/jewellery.jsp to see the chart
itself.

As my own side note, on Postgres 7.0.2, I at one point tried creating
a view which said

CREATE VIEW silver_view AS
SELECT * from jcombo_query WHERE metal_uid = 1 ;

and so on for elec, gold, plat. And then used these to simplify the
main query. This caused Postgres to go away permanently, and I had
to manually delete the database.

And the original query was so slow, that I decided to, for the time
being, do a

SELECT * INTO jewellery FROM metals_query ORDER BY stone_uid ;

Ol
--
If at first you don't succeed, skydiving is not for you...

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephan Szabo 2000-09-07 00:42:07 Re: That killer 3rd join...
Previous Message Chris 2000-09-06 23:02:35 Re: Inheritance and Constraint