Re: Planner Row Estimate with Function

Поиск
Список
Период
Сортировка
От Michael Fork
Тема Re: Planner Row Estimate with Function
Дата
Msg-id 925224.54894.qm@web59002.mail.re1.yahoo.com
обсуждение исходный текст
Ответ на Re: Planner Row Estimate with Function  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Planner Row Estimate with Function  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
springboard_v2=# SELECT version();
                                             version
--------------------------------------------------------------------------------------------------
 PostgreSQL 8.3.7 on amd64-portbld-freebsd7.2, compiled by GCC cc (GCC) 4.2.1 20070719  [FreeBSD]
(1 row)

Yes, this is partial index.  I should have included the index definition earlier:

# CREATE INDEX CONCURRENTLY idx_event_card_id ON trail.event(parsecardidfromreferencecode(reference_code)) WHERE type =
'CREDIT';Thanks. 


Michael



----- Original Message ----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Fork <mfork00@yahoo.com>
Cc: pgsql-general@postgresql.org
Sent: Tue, December 29, 2009 3:43:06 PM
Subject: Re: [GENERAL] Planner Row Estimate with Function

Michael Fork <mfork00@yahoo.com> writes:
> I have an index scan on a custom function that is returning a wildly incorrect row estimate that is throwing off the
restof the query planning.  The result of the function is roughly unique - there are a handful with multiple entries -
butthe planner is estimating 227,745 rows.  I re-ran ANALYZE on the table and the results did not change.  Any
suggestionson how to get more accurate planner result? 

What PG version is this exactly?

Also, what happened to the type='CREDIT' condition in your query?  Is
that a partial index?

            regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Idle processes chewing up CPU?
Следующее
От: Michael Fork
Дата:
Сообщение: Re: Planner Row Estimate with Function