Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
>> Bryce Nesbitt wrote:
>>
>>> They occur in finite time. That's good, thanks. But jeeze, can't
>>> postgres figure this out for itself?
>>>
>> I'm sure you wouldn't appreciate it if PostgreSQL did a full table scan
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bryce Nesbitt wrote:
>> They occur in fine time. That's good, thanks. But jeeze, can't
>> postgres figure this out for itself?
> I'm sure you wouldn't appreciate it if PostgreSQL did a full table scan
> before each query to figure out the total siz
Peter Eisentraut wrote:
> Bryce Nesbitt wrote:
>
>>> It seems pretty clear that you've never vacuumed nor analyzed these
>>> tables ... else the planner would have some clue about their sizes.
>>> Do that and then see what you get.
>>>
>> They occur in fine time. That's good, thanks. Bu
Bryce Nesbitt wrote:
> > It seems pretty clear that you've never vacuumed nor analyzed these
> > tables ... else the planner would have some clue about their sizes.
> > Do that and then see what you get.
>
> They occur in fine time. That's good, thanks. But jeeze, can't
> postgres figure this out
Tom Lane wrote:
> Bryce Nesbitt <[EMAIL PROTECTED]> writes:
>
>> Tom Lane wrote:
>>
>>> What does EXPLAIN show for this and for the base query?
>>>
>
>
>>-> Seq Scan on event (cost=0.00..0.00 rows=1 width=408)
>> Filter: (reconciled = false)
>>
>
>
>
Bryce Nesbitt <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What does EXPLAIN show for this and for the base query?
>-> Seq Scan on event (cost=0.00..0.00 rows=1 width=408)
> Filter: (reconciled = false)
> select count(*) from event;
> ---
> 116226
It seems pret
Tom Lane wrote:
> Bryce Nesbitt <[EMAIL PROTECTED]> writes:
>
>> update event set reconciled=true where event_id in
>> (select event_id from event join token using (token_number)
>> where token_status=50 and reconciled=false LIMIT 1);
>>
>> On a 4 CPU machine, 2 CPU's peg at 10
Bryce Nesbitt <[EMAIL PROTECTED]> writes:
> update event set reconciled=true where event_id in
> (select event_id from event join token using (token_number)
> where token_status=50 and reconciled=false LIMIT 1);
> On a 4 CPU machine, 2 CPU's peg at 100%, and the request just eats CPU
If I do:
select event_id from event join token using
(token_number) where token_status=50 and
reconciled=false limit 1;
Then:
update event set reconciled=true where event_id={XXX};
It returns in about a second, or less. But If I do the same thing with
the IN syntax:
