Skip site navigation (1) Skip section navigation (2)

Re: hash index improving v3

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Alex Hunsaker <badalex(at)gmail(dot)com>, Kenneth Marshall <ktm(at)rice(dot)edu>, Xiao Meng <mx(dot)cogito(at)gmail(dot)com>, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: hash index improving v3
Date: 2008-09-23 13:34:39
Message-ID: 1222176879.4445.361.camel@ebony.2ndQuadrant (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Tue, 2008-09-23 at 09:13 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > Thinks: Why not just sort all of the time and skip the debate entirely?
> 
> The sort is demonstrably a loser for smaller indexes.  Admittedly,
> if the index is small then the sort can't cost all that much, but if
> the (correct) threshold is some large fraction of shared_buffers then
> it could still take awhile on installations with lots-o-buffers.

The other realisation is that for large indexes, giving them more
maintenance_work_mem probably will make them build faster 'cos we'll be
sorting. So "give big indexes more memory" is still true *enough* to be
broadly consistent, explainable and understandable. I do explain things
in more detail on some courses, but pithy rules help busy people.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


In response to

pgsql-hackers by date

Next:From: Greg Sabino MullaneDate: 2008-09-23 13:35:56
Subject: Re: pg_type.h regression?
Previous:From: Gregory StarkDate: 2008-09-23 13:33:32
Subject: Re: Initial prefetch performance testing

pgsql-patches by date

Next:From: Simon RiggsDate: 2008-09-23 15:42:21
Subject: Re: [PATCHES] Infrastructure changes for recovery
Previous:From: Simon RiggsDate: 2008-09-23 13:27:02
Subject: Re: hash index improving v3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group