Re: PostgreSQL does CAST implicitely between int and a domain derived from int

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: PostgreSQL does CAST implicitely between int and a domain derived from int
Дата
Msg-id 603c8f070908271035h2dbdf1f0heafa475e560a8118@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL does CAST implicitely between int and a domain derived from int  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Jean-Michel Pouré <jm@poure.com>)
Список pgsql-performance
2009/8/27 Kevin Grittner <Kevin.Grittner@wicourts.gov>:
> It is *possible* that if you boost your default_statistics_target and
> run ANALYZE (or VACUUM ANALYZE), it will recognize that it isn't a
> good idea to read backwards on that index.  I would try it and see, if
> that's practical for you.

I notice this in one of the plans:

->  Bitmap Index Scan on term_node_tid_idx  (cost=0.00..4.94 rows=91
width=0) (actual time=0.014..0.014 rows=0 loops=1)
     Index Cond: ((tid)::integer = 3)

That's a pretty bad estimate for a scan of a single relation with a
filter on one column.

I'd like to see the output of:

SELECT MIN(tid), MAX(tid), SUM(1) FROM term_node;
SHOW default_statistics_target;

By the way, why does EXPLAIN not display the name of the table as well
as the index when it performs a bitmap index scan?  It does do so for
a regular index scan.

What version of PG is this again?

...Robert

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

Предыдущее
От: Jean-Michel Pouré
Дата:
Сообщение: Re: PostgreSQL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL does CAST implicitely between int and a domain derived from int