| From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
|---|---|
| To: | "Don Baccus" <dhogaza(at)pacifier(dot)com>, "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 10:05:49 |
| Message-ID: | 002101bf9af8$b085f840$2801007e@tpf.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> -----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'.
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniele Medri | 2000-03-31 10:34:39 | Re: ...copy hack |
| Previous Message | Michael Meskes | 2000-03-31 10:02:45 | Re: BIT datatype |