From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-performance(at)postgresql(dot)org, Jean-Michel Pouré <jm(at)poure(dot)com> |
Subject: | Re: PostgreSQL does CAST implicitely between int and a domain derived from int |
Date: | 2009-08-27 17:35:02 |
Message-ID: | 603c8f070908271035h2dbdf1f0heafa475e560a8118@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2009/8/27 Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-08-27 18:05:13 | Re: PostgreSQL does CAST implicitely between int and a domain derived from int |
Previous Message | Jean-Michel Pouré | 2009-08-27 17:01:41 | Re: PostgreSQL |