Skip site navigation (1) Skip section navigation (2)

RE: slow join on postgresql6.5

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Wenjin Zheng" <wenjin(dot)zheng(at)lsbc(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: slow join on postgresql6.5
Date: 2000-03-31 14:33:49
Message-ID: 3.0.1.32.20000331063349.00f783f4@mail.pacifier.com (view raw or flat)
Thread:
Lists: pgsql-hackers
At 07:05 PM 3/31/00 +0900, Hiroshi Inoue wrote:
>> -----Original Message-----
>> From: majordomo-owner(at)hub(dot)org [mailto:majordomo-owner(at)hub(dot)org]On Behalf
>> Of Don Baccus
>> 
>> Whatever ... in this particular case  - referential integrity 
>> with MATCH <unspecified> and MATCH PARTIAL and multi-column
>> foreign keys - performance will likely drop spectacularly once the
>> leading column is NULL, while (say) with Oracle you'd expect much
>> less of a performance hit. 
>>
>
>As for NULL,it seems possible to look up NULL keys in a btree index
>because NULL == NULL for btree indexes.
>I've wondered why PostgreSQL's planner/executor never looks up
>indexes for queries using 'IS NULL'.

Unfortunately for the RI MATCH PARTIAL case, NULL is a "wildcard".

This doesn't affect the validity of your observation in the general
case, though.



- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

In response to

Responses

pgsql-hackers by date

Next:From: Lamar OwenDate: 2000-03-31 14:36:30
Subject: Re: pgAccess change
Previous:From: Lamar OwenDate: 2000-03-31 14:30:44
Subject: Re: Regress test updates: status report

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group