On Mon, Mar 09, 2009 at 11:45:38AM +0100, Christian Schröder wrote:
> Scott Marlowe wrote:
>>> 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
>
2009/3/6 Christian Schröder
> Hi list,
> if I want to find all records from a table that don't have a matching
> record in another table there are at least two ways to do it: Using a left
> outer join or using a subselect. I always thought that the planner would
> create identical plans for both
2009/3/9 Christian Schröder :
> Scott Marlowe wrote:
>>>
>>> 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.
>>>
>>
>> Definitely.
>>
>
>
Scott Marlowe wrote:
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.
Definitely.
I understand why this is advisable; however, something
2009/3/9 Christian Schröder :
>
> I understand why this is advisable; however, something inside me hates the
> idea to put this kind of database specific stuff inside an application. How
> about portability? Why does the application developer have to know about
> database internals? He knows sql,
On Sun, Mar 8, 2009 at 12:47 PM, Grzegorz Jaśkiewicz wrote:
> work_mem constraints amount of memory allocated per connection, hence
Actually, it's per sort. And there can be > 1 sort per query.
> you can run out of memory if too many connections try to use too much
> of it at the same time, that
On Sun, Mar 8, 2009 at 6:37 PM, Christian Schröder 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
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?
You're probably at the threshold where it doesn't think the hashtable
would fit in work_mem.
=?ISO-8859-1?Q?Christian_Schr=F6der?= writes:
> if I want to find all records from a table that don't have a matching
> record in another table there are at least two ways to do it: Using a
> left outer join or using a subselect. I always thought that the planner
> would create identical plans
On Thu, Mar 5, 2009 at 11:25 PM, Christian Schröder wrote:
> Hi list,
> if I want to find all records from a table that don't have a matching record
> in another table there are at least two ways to do it: Using a left outer
> join or using a subselect. I always thought that the planner would crea
Hi list,
if I want to find all records from a table that don't have a matching
record in another table there are at least two ways to do it: Using a
left outer join or using a subselect. I always thought that the planner
would create identical plans for both approaches, but actually they are
q
11 matches
Mail list logo
