Re: GiST index performance
От
Matthew Wakeling
Тема
Re: GiST index performance
Дата
Msg-id
alpine.DEB.2.00.0904161900500.22330@aragorn.flymine.org
Ответ на
Re: GiST index performance (Tom Lane)
Список
Дерево обсуждения
GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: GiST index performance Tom Lane <tgl@sss.pgh.pa.us>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance Tom Lane <tgl@sss.pgh.pa.us>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance Tom Lane <tgl@sss.pgh.pa.us>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
Re: GiST index performance dforum <dforums@vieonet.com>
Re: GiST index performance Tom Lane <tgl@sss.pgh.pa.us>
Re: GiST index performance Craig Ringer <craig@postnewspapers.com.au>
Re: GiST index performance Matthew Wakeling <matthew@flymine.org>
On Thu, 16 Apr 2009, Tom Lane wrote:
> Hmm, and what is shared_buffers set to? How big are the tables and
> other indexes used in the query? We still have to explain why the
> inner nestloop got slower, and it's hard to see that unless something
> stopped fitting in cache.
I just noticed that someone has started running a big java program (6GB
RAM so far) on that machine. Maybe it was running during the bad run. I'll
see if I can re-run those two queries later on when the machine is idle.
shared_buffers = 500MB
Location table: 336 MB
Gene table: 124 MB
Primer table: 103 MB
location__key_all index: 334 MB
Matthew
--
For those of you who are into writing programs that are as obscure and
complicated as possible, there are opportunities for... real fun here
-- Computer Science Lecturer
В списке pgsql-performance по дате отправления