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
before each query
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 pretty clear
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)
select count(*) from
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 for
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. But jeeze, can't
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 size of the
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:
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
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 100%, and the
