| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bradley Baetz <bbaetz(at)acm(dot)org> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: New hashed IN code ignores distinctiveness of subquery |
| Date: | 2003-01-27 05:00:08 |
| Message-ID: | 19654.1043643608@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Bradley Baetz <bbaetz(at)acm(dot)org> writes:
> By cached, do you mean PREPARE stuff, or something else?
PREPARE, and cached plans in plpgsql, and cached plans in SPI, and
cached plans for foreign keys (though probably those never use IN)
and perhaps other places I'm not thinking of at the moment.
> However, its much faster (although not as fast as sticking the DISTINCT
> in there myself), but the actual rows coming from the sort is really odd
> - where is that number coming from? How can sorting 9 rows take 44476
> anythings?
We're back full circle to my original comment about rescans in
mergejoin. The EXPLAIN ANALYZE instrumentation counts a re-fetch
as another returned row.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bradley Baetz | 2003-01-27 07:29:19 | Re: [BUGS] New hashed IN code ignores distinctiveness of subquery |
| Previous Message | Bradley Baetz | 2003-01-27 04:50:41 | Re: New hashed IN code ignores distinctiveness of subquery |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2003-01-27 06:20:04 | Re: Can we revisit the thought of PostgreSQL 7.2.4? |
| Previous Message | Bradley Baetz | 2003-01-27 04:50:41 | Re: New hashed IN code ignores distinctiveness of subquery |