>Is that the one off gborg? It's broken because the equality function is
>marked volatile, and so the planner is afraid to try to use it for
>merging or hashing. (It's also not marked strict, which means you can
>trivially crash the backend by passing it a null ...)
Tom, you are a genius. I chan
>Is that the one off gborg? It's broken because the equality function is
>marked volatile, and so the planner is afraid to try to use it for
>merging or hashing. (It's also not marked strict, which means you can
>trivially crash the backend by passing it a null ...)
It is the one from gborg. Tha
CG <[EMAIL PROTECTED]> writes:
>> If packet_status is large, that seems like a perfectly reasonable plan
>> to me. If not ... what data type is packet_uuid? Is its equality op
>> marked mergeable or hashable?
> It is of type uniqueidentifier ...
Is that the one off gborg? It's broken because
>If packet_status is large, that seems like a perfectly reasonable plan
>to me. If not ... what data type is packet_uuid? Is its equality op
>marked mergeable or hashable?
It is of type uniqueidentifier ...
CREATE OPERATOR =(
PROCEDURE = uniqueidentifier_eq,
LEFTARG = uniqueidentifier,
CG <[EMAIL PROTECTED]> writes:
> I'm still getting the nested loop for a join.
> Nested Loop (cost=1.00..100013378.98 rows=2206 width=145) (actual
> time=46.743..18202.318 rows=2225 loops=1)
> -> Index Scan using packet_user_idx on packet dp (cost=0.00..88.03
> rows=2206 width=125)
- Original Message
From: Tom Lane <[EMAIL PROTECTED]>
To: CG <[EMAIL PROTECTED]>
Cc: pgsql-sql@postgresql.org
Sent: Tuesday, September 19, 2006 11:03:07 AM
Subject: Re: [SQL] Nested loops are killing throughput
CG <[EMAIL PROTECTED]> writes:
> -
CG <[EMAIL PROTECTED]> writes:
> -> Nested Loop (cost=0.00..744.28 rows=1 width=16)
> (actual time=31.227..6980.765 rows=5436 loops=1)
> -> Nested Loop (cost=0.00..135.29 rows=101
> width=16) (actual time=25.514..273.660 rows=5436 loops=1)
> ...
>
Postgresql 8.1
I've tried turning off nested loops to see what the query planner would choose
instead of nested loops. It chose a hash join, and it still had a nested loop
in the mix! How can I entice the query planner to use a simpler join scheme?
What criteria is used to determine whether or
