On 8 Oct 2004 at 16:04, Tom Lane wrote:
> "Gary Doades" <[EMAIL PROTECTED]> writes:
> > If I remove the redundant clauses, the planner now estimates 1000 rows returned
> > from
> > the table, not unreasonable since it has no statistics. But *why* in that case,
> > with *more*
> > estimated row
"Gary Doades" <[EMAIL PROTECTED]> writes:
> If I remove the redundant clauses, the planner now estimates 1000 rows returned from
> the table, not unreasonable since it has no statistics. But *why* in that case, with
> *more*
> estimated rows does it choose to materialize that table (26 rows) 573
Oops, forgot to mention:
PostgreSQL 8.0 beta 2 Windows.
Thanks,
Gary.
On 8 Oct 2004 at 20:32, Gary Doades wrote:
>
> I'm looking at one of my standard queries and have encountered some strange
> performance
> problems.
>
> The query below is to search for vacant staff member date/time slots
On Thu, 25 Mar 2004, Ara Anjargolian wrote:
> I've run into this odd planner choice which I don't quite understand.
>
> I have two tables articles, users and
> articles.article_id and users.user_id are primary keys.
>
> Insides articles there are two optional fields author_id1, author_id2
> whic
"Ara Anjargolian" <[EMAIL PROTECTED]> writes:
> jargol=# explain select user_id, first_names, last_name from articles, users
> where article_id = 5027 and (articles.author_id1 = users.user_id or
> articles.author_id2 = users.user_id);
> Why does it think it MUST do a seq-scan in the second case?
