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: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: Fast GiST index build
Date: Mon, 27 Jun 2011 17:34:39 +0300
Message-ID: <4E0894FF.8080202@enterprisedb.com> (raw)
In-Reply-To: <BANLkTinK-ZL-yQCNtKZLfGS=8VGmO13b8g@mail.gmail.com>
References: <BANLkTikgOQ1+r=A9b08szNTeEWsk-cNMMg@mail.gmail.com>
	<4DEC84D7.7040602@enterprisedb.com>
	<4DECB141.2040707@enterprisedb.com>
	<BANLkTimDQewwaumOaDtFjSb+2edn-E_dNg@mail.gmail.com>
	<BANLkTimoH+8tsm6LG1jjFNY7xiFXHeNDDA@mail.gmail.com>
	<BANLkTinWE4DX41=eXnX+YWqFXZ_xJqOC8w@mail.gmail.com>
	<BANLkTinMB-GSjFDThc0o9hRWa+_dJJXPZg@mail.gmail.com>
	<4DF8676F.9040801@enterprisedb.com>
	<BANLkTimr___BFy+98t36tkbUvvavUzjV9A@mail.gmail.com>
	<BANLkTi=x0Ck1z_NbkqeqvuKXs9kHOR+5WQ@mail.gmail.com>
	<BANLkTikP6RAYmUriquQEdKjEBviTH2vWRQ@mail.gmail.com>
	<4DFA4AE5.1010806@enterprisedb.com>
	<BANLkTinN6C8q61Fb8ASZVOPbYq7VoqoHOw@mail.gmail.com>
	<BANLkTin=gyX5PJW-JaN59uqRBSgdDHVNNA@mail.gmail.com>
	<BANLkTikSbaun6Sf8hJSkO0D4nu7VC2O35A@mail.gmail.com>
	<4E044D68.5070605@enterprisedb.com>
	<BANLkTi=umLx8LBCSmALKpoGTFguqQxQ61w@mail.gmail.com>
	<BANLkTinK-ZL-yQCNtKZLfGS=8VGmO13b8g@mail.gmail.com>

On 27.06.2011 13:45, Alexander Korotkov wrote:
> I've added information about testing on some real-life dataset to wiki page.
> This dataset have a speciality: data is ordered inside it. In this case
> tradeoff was inverse in comparison with expectations about "fast build"
> algrorithm. Index built is longer but index quality is significantly better.
> I think high speed of regular index built is because sequential inserts are
> into near tree parts. That's why number of actual page reads and writes is
> low. The difference in tree quality I can't *convincingly explain now.*
> I've also maked tests with shuffled data of this dataset. In this case
> results was similar to random generated data.

Once again, interesting results.

The penalty function is called whenever a tuple is routed to the next 
level down, and the final tree has the same depth with and without the 
patch, so I would expect the number of penalty calls to be roughly the 
same. But clearly there's something wrong with that logic; can you 
explain in layman's terms why the patch adds so many gist penalty calls? 
And how many calls does it actually add, can you gather some numbers on 
that? Any ides on how to mitigate that, or do we just have to live with 
it? Or maybe use some heuristic to use the existing insertion method 
when the patch is not expected to be helpful?

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



view thread (114+ messages)  latest in thread

Message-ID: <4E0894FF.8080202@enterprisedb.com>
Permalink:  ../4E0894FF.8080202@enterprisedb.com/
Also on:    postgresql.org/message-id/4E0894FF.8080202@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
  Subject: Re: WIP: Fast GiST index build
  In-Reply-To: <4E0894FF.8080202@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