Re: SeqScan costs

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: SeqScan costs
Дата
Msg-id 87r68s933v.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на SeqScan costs  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: SeqScan costs  (Decibel! <decibel@decibel.org>)
Список pgsql-hackers
>>>>> "Decibel!" == Decibel!  <decibel@decibel.org> writes:
Decibel> Roughly what I get on my MBP (I'm about a factor of 2Decibel> slower). This makes me think it's an issue of
havingto slogDecibel> through an entire page one row at a time vs just using theDecibel> index. To test this I tested
selectingi=200 (remember weDecibel> start filling data at the back of the page, so 200 wouldDecibel> actually be the
front,and I'm assuming the first value thatDecibel> would be hit) vs i=1. With seqscans, I saw about a 10%Decibel>
difference.With index scans the difference was moot, butDecibel> also note that now index scans are in-between seqscans
inDecibel>performance.
 

The problem is that by looking for a constant row, you're actually
eliminating the entire effect being tested, because the uncorrelated
subselect is run ONCE as an initplan, and the entire query time is
then spent elsewhere. The differences in runtime you're seeing are
pure noise (the fact that you had to increase the iteration count so
much should have been a clue here).

-- 
Andrew (irc:RhodiumToad)


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

Предыдущее
От: "Marko Kreen"
Дата:
Сообщение: Re: Replay attack of query cancel
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Transaction-controlled robustness for replication