My Next Task: Finding a Stress Test Harness to Load, and Query Data.
Anyone have ideas?
I am eagerly awaiting the * DESTRUCTION* ** of Oracle around here, and
"yes" I am an oracle DBA and think it's */ very /*// good technology.
Have you tried the simple 'gmake test'?
Other than that, try htt
Jocelyn Turcotte <[EMAIL PROTECTED]> writes:
> But if I plug another condition with a OR like this:
> select *
> from rt_node n, rt_edge e
> where node_id = 2
> and (e.start_node_id = n.node_id or e.end_node_id = n.node_id);
> I get this plan, it stop using the index!:
I'm afraid you're stuck w
Thanks John
it dont seems to work, but in my context I only needed data from the
rt_node table so I tried this:
select *
from rt_node n
where node_id = 2
and exists (select edge_id from rt_edge where start_node_id =
n.node_id or end_node_id = n.node_id)
and it gave me this plan (even if I remove
You just couldn't help yourself, could you? :-)
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Jocelyn Turcotte wrote:
Hi all
i dont know if this is normal, but if yes i would like to know why and
how I could do it another way other than using unions.
The only thing that *might* work is if you used an index on both keys.
So if you did:
CREATE INDEX rt_edge_start_end_node ON rt_edge(s
Hi all
i dont know if this is normal, but if yes i would like to know why and
how I could do it another way other than using unions.
(I tried on postgresql 7.4 and 8.0.3, made my vacuum analyse just before)
Here is my simple query:
select *
from rt_node n, rt_edge e
where node_id = 2
and e.star
Title: RE: [PORTS] Which library has these symbols? -- Eureka
64-bit PG 8.0.2. is up and running on AIX5.3/power5
YES! ! !
The major thing: setting some quirky LDFLAGS.
Anyone interested in details, please ping.
Thanks to Nick Addington, Vincent Vanwynsberghe, my SA, Sergey,
and
Thanks for the prompt reply !! Actually migration is inevitable. We have a
totally messed up schema, not normalized and stuff like that. So the goal
of
the migration is to get a new and better normalized schema. That part is
done already. Now the decision point is, should we go with postgres or
