| From: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
|---|---|
| To: | Christian Schröder <cs(at)deriva(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Performance of subselects |
| Date: | 2009-03-08 18:47:07 |
| Message-ID: | 2f4958ff0903081147o5c3137c8uebc24e761f4beae7@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sun, Mar 8, 2009 at 6:37 PM, Christian Schröder <cs(at)deriva(dot)de> wrote:
> Tom Lane wrote:
>>
>> No, they're not the same; NOT IN has different semantics for nulls.
>>
>
> But in this case the column in the subselect has a not-null constraint. Does
> the planner recognize this constraint?
not in this case, afaik
>> You're probably at the threshold where it doesn't think the hashtable
>> would fit in work_mem.
work_mem constraints amount of memory allocated per connection, hence
you can run out of memory if too many connections try to use too much
of it at the same time, that's why it is advisable to set work_mem per
connection/query, should the connection/query require more.
--
GJ
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Carl Sopchak | 2009-03-08 18:47:55 | Re: Newbie questions relating to transactions |
| Previous Message | Christian Schröder | 2009-03-08 18:37:32 | Re: Performance of subselects |