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
