Re: PG8.2.1 choosing slow seqscan over idx scan

Поиск
Список
Период
Сортировка
От Jeremy Haile
Тема Re: PG8.2.1 choosing slow seqscan over idx scan
Дата
Msg-id 1169059600.23210.1169763553@webmail.messagingengine.com
обсуждение исходный текст
Ответ на Re: PG8.2.1 choosing slow seqscan over idx scan  ("Chad Wagner" <chad.wagner@gmail.com>)
Список pgsql-performance
> It would be nice if the database could
> learn to estimate these values, as newer versions of Oracle does.

That would be really nice since it would take some of the guess work out
of it.

> Yes, cluster would rebuild the table for you.  I wouldn't do anything too
> intrusive, run with the random_page_cost lowered, perhaps vacuum full,
> reindex, and see what happens.

I'll try doing the vacuum full and reindex tonight since they require
exclusive locks.

> Yep, my thoughts exactly.  Partitioning support is PostgreSQL is there,
> but  it needs a bit more of a tighter integration into the core (I shouldn't
> have to create a view, n tables, n rules, etc).  Additionally, I have read
> that at some point when you have "y" partitions the performance degrades,
> haven't really looked into it myself.

Yeah - I haven't setup partitioning in PostgreSQL before, although I've
read quite a bit about it.  I've talked about getting improved syntax
for partitioning in PostgreSQL.  MySQL's syntax is much simpler and more
intuitive compared to setting them up with Postgres - it would be nice
if PostgreSQL adopted a similar syntax where partitions were first-class
citizens.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: PG8.2.1 choosing slow seqscan over idx scan
Следующее
От: "Jeremy Haile"
Дата:
Сообщение: Re: PG8.2.1 choosing slow seqscan over idx scan