Re: sub select performance due to seq scans

Поиск
Список
Период
Сортировка
От H Hale
Тема Re: sub select performance due to seq scans
Дата
Msg-id 20060731160902.37302.qmail@web88007.mail.re2.yahoo.com
обсуждение исходный текст
Ответ на Re: sub select performance due to seq scans  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: sub select performance due to seq scans  (H Hale <hhale21@rogers.com>)
Список pgsql-performance
Tom,

It is unique.

Indexes:
    "flatomfilesysentry_pkey" PRIMARY KEY, btree (objectid)
    "capsa_flatomfilesysentry_name_idx" btree (name)
Foreign-key constraints:
    "objectid" FOREIGN KEY (objectid) REFERENCES capsa_sys.master(objectid) ON DELETE CASCADE


Tom Lane <tgl@sss.pgh.pa.us> wrote:
H Hale writes:
> -> Bitmap Heap Scan on flatomfilesysentry (cost=2.00..274.38 rows=3238 width=30) (actual time=0.011..0.013 rows=1 loops=6473)
> Recheck Cond: (flatomfilesysentry.objectid = "outer".dstobj)
> -> Bitmap Index Scan on flatomfilesysentry_pkey (cost=0.00..2.00 rows=3238 width=0) (actual time=0.007..0.007 rows=1 loops=6473)
> Index Cond: (flatomfilesysentry.objectid = "outer".dstobj)

Well, there's our estimation failure: 3238 rows expected, one row
actual.

What is the data distribution of flatomfilesysentry.objectid?
It looks from this example like it is unique or nearly so,
but the planner evidently does not think that.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: PostgreSQL scalability on Sun UltraSparc T1
Следующее
От: Axel Rau
Дата:
Сообщение: Re: directory tree query with big planner variation