On Thu, Sep 07, 2000 at 10:23:57AM -0300, The Hermit Hacker wrote:
> BTW, what do you mean by 'went away'? crashed, or just hung there?
Stopped using CPU, stopped responding to signals (except in the end -9),
and when I did finally kill it (the following day, to give it chance to
do what it was
On Thu, Sep 07, 2000 at 02:11:38PM +0100, Oliver Smith wrote:
> However, when I did that, postgres went away. I'll give your idea a try,
> it looks quite promising.
I still found this took quite a long time to process the query. So - I created
the four views, silver, elec, gold, plat, and a new v
On Thu, 7 Sep 2000, Oliver Smith wrote:
> CREATE VIEW silver AS
> SELECT * FROM jcombo_query WHERE metal_uid = 1 ;
>
> CREATE VIEW elec AS
> ...
>
> However, when I did that, postgres went away. I'll give your idea a try,
> it looks quite promising.
Ya, looked at that ... you were doing a VI
On Wed, Sep 06, 2000 at 10:52:34PM -0300, The Hermit Hacker wrote:
> SELECT
> stone_name, st.stone_uid, stone_modifies, stone_difficulty, stone_cost,
> silver.jtyp_name AS silver_name, (silver.metal_cost + stone_cost) AS Expr1,
> silver.jcombo_stats AS silver_stats,
> elec.jtyp_name AS el
Stephan Szabo <[EMAIL PROTECTED]> writes:
> As a separate issue I can't even do the query listed below on my
> machine with reasonably current sources, as it fails after a while with
> an ExecRestrPos: node type 18 not supported. Haven't looked yet...
Yes, there's a nasty little planning bug in
Just played with this a little bit, and I'm not 100% certain whether I'm
getting the "desired results", but why not do something like:
SELECT
stone_name, st.stone_uid, stone_modifies, stone_difficulty, stone_cost,
silver.jtyp_name AS silver_name, (silver.metal_cost + stone_cost) AS Expr1,
For the record, I have a similar query in a program I developed that
aliases the same table multiple times and the performance on that one is
terrible as well. In fact, it's the only query of the many that program
uses that isn't downright snappy. Short of a table redesign (which I may
do anyway),
On Thu, 7 Sep 2000, Oliver Smith wrote:
> 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 att
> 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 spe
In order to explore some postgres performance options with table
collation, I decided to use a little experimental dabase to try out
some of the options I saw. What I want to create queries to combine
data from 2+ tables into individual rows.
So - being a bit of an EQ player, I cobbled together a
10 matches
Mail list logo
