| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Christophe Pettus <xof(at)thebuild(dot)com>, pgsql-general list <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: 'alternatives' |
| Date: | 2012-11-28 22:50:15 |
| Message-ID: | 18562.1354143015@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Andres Freund <andres(at)anarazel(dot)de> writes:
> The commit introducing this is:
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=bd3daddaf232d95b0c9ba6f99b0170a0147dd8af
> What that does to add hashing support for IN(). But hashing can be
> pessimal in comparison to a explicit check if only a few values come in,
> so this can be checked at runtime after the above commit...
Yeah. If you look at the subplans, one is designed for retail probes
and the other is designed for sucking up the entire subquery result into
a hashtable. EXPLAIN ANALYZE will show you that only one gets used at
runtime. (The idea of dynamic switchover hasn't gotten anywhere yet.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-11-28 23:13:00 | Re: pg_listening_channels() |
| Previous Message | Thomas Kellerer | 2012-11-28 22:43:25 | Updateable VIEWS and the manual |