pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Jesper Krogh <jesper@krogh.cc>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: Fast GiST index build
Date: Sun, 26 Jun 2011 13:18:06 +0300
Message-ID: <4E07075E.30900@enterprisedb.com> (raw)
In-Reply-To: <BANLkTinf3eL6T_8SHP+7QfMu71_OGBwN3g@mail.gmail.com>
References: <BANLkTikgOQ1+r=A9b08szNTeEWsk-cNMMg@mail.gmail.com>
	<4DEC84D7.7040602@enterprisedb.com>
	<4E058830.8070009@krogh.cc>
	<BANLkTinf3eL6T_8SHP+7QfMu71_OGBwN3g@mail.gmail.com>

On 25.06.2011 11:23, Alexander Korotkov wrote:
> On Sat, Jun 25, 2011 at 11:03 AM, Jesper Krogh<jesper@krogh.cc>  wrote:
>
>> * Wouldn't it be natural to measure the performance benefits of
>>    disc-bound tests in an SSD setup?
>>
> Sure, it would be great to run performance tests on SSD drives too.
> Unfortunately, I don't have corresponding test platform just now.

Anyone have an SSD setup to run some quick tests with this?

>> In terms of random IO an SSD can easily be x100 better than rotating
>> drives and it would be a shame to optimize "against" that world?
>
> Actually, I'm not sure that IO is bottle neck of GiST index build on SSD
> drives. It's more likely for me that CPU becomes a bottle neck in this case
> and optimizing IO can't give much benefit. But anyway, the value of this
> work can be in producing better index in some cases and SSD drive lifetime
> economy due to less IO operations.

Yeah, this patch probably doesn't give much benefit on SSDs, not the 
order of magnitude improvements it gives on HDDs anyway. I would expect 
there to still be a small gain, however. If you look at the comparison 
of CPU times on Alexander's tests, the patch doesn't add that much CPU 
overhead: about 5% on the point_ops tests. I/O isn't free on SSDs 
either, so I would expect the patch to buy back that 5% increase in CPU 
overhead by reduced time spent on I/O even on a SSD.

It's much worse on the gist_trgm_ops test case, so this clearly depends 
a lot on the opclass, but even that should be possible to optimize quite 
a bit.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com



view thread (114+ messages)  latest in thread

Message-ID: <4E07075E.30900@enterprisedb.com>
Permalink:  ../4E07075E.30900@enterprisedb.com/
Also on:    postgresql.org/message-id/4E07075E.30900@enterprisedb.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: heikki.linnakangas@enterprisedb.com, aekorotkov@gmail.com, jesper@krogh.cc
  Subject: Re: WIP: Fast GiST index build
  In-Reply-To: <4E07075E.30900@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox