pg.ddx.io  pgsql-patches@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jonah H. Harris <jonah.harris@gmail.com>
Cc: Alex Hunsaker <badalex@gmail.com>
Cc: Kenneth Marshall <ktm@rice.edu>
Cc: Xiao Meng <mx.cogito@gmail.com>
Cc: Zdenek Kotala <Zdenek.Kotala@sun.com>
Cc: pgsql-patches@postgresql.org
Subject: Re: hash index improving v3
Date: Tue, 23 Sep 2008 14:05:15 +0100
Message-ID: <1222175115.4445.344.camel@ebony.2ndQuadrant> (raw)
In-Reply-To: <25193.1222172194@sss.pgh.pa.us>
References: <34d269d40809052249h59750f83v4b19a50d0555580@mail.gmail.com>
	<34d269d40809091823t204e252fl246443be71aed9ff@mail.gmail.com>
	<20080910130401.GG6714@it.is.rice.edu>
	<34d269d40809102049y2599a381kf409c0b5f18b6170@mail.gmail.com>
	<34d269d40809102117g470c4d25l55be7898fc43fc40@mail.gmail.com>
	<20080911152437.GM6714@it.is.rice.edu>
	<34d269d40809111951s7bac44cfk5dc9244693dd777c@mail.gmail.com>
	<20080912142921.GB26773@it.is.rice.edu>
	<7246.1221445012@sss.pgh.pa.us>
	<34d269d40809222025k2b2252dft89db471649c8eef8@mail.gmail.com>
	<36e682920809222030k49293e85jc57429296c5d2d76@mail.gmail.com>
	<17323.1222142759@sss.pgh.pa.us>
	<1222144262.4445.265.camel@ebony.2ndQuadrant>
	<18049.1222145316@sss.pgh.pa.us>
	<1222146936.4445.290.camel@ebony.2ndQuadrant>
	<25193.1222172194@sss.pgh.pa.us>


On Tue, 2008-09-23 at 08:16 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > maintenance_work_mem is already used for 3 separate operations that bear
> > little resemblance to each other. If it's appropriate for all of those
> > then its appropriate for this usage also.
> 
> No, it isn't.
> 
> The fundamental point here is that this isn't a memory allocation
> parameter; it's a switchover threshold between two different behaviors.

That's a little confusing since sorts switch their behaviour also, but
use (some form of) work_mem, which is *also* their max allocation. I see
the difficulty in understanding the algorithm's behaviour now.

So shared_buffers is the wrong parameter, but even if we had a parameter
it would be very difficult to set it. 

Thinks: Why not just sort all of the time and skip the debate entirely?
I thought the main use case was for larger indexes, since that's when
the number of levels in the index is significantly less than btrees? Do
we need to optimise creation time of smaller hash indexes at all?

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




view thread (63+ messages)  latest in thread

Message-ID: <1222175115.4445.344.camel@ebony.2ndQuadrant>
Permalink:  ../1222175115.4445.344.camel@ebony.2ndQuadrant/
Also on:    postgresql.org/message-id/1222175115.4445.344.camel@ebony.2ndQuadrant

 · 

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-patches@postgresql.org
  Cc: simon@2ndQuadrant.com, tgl@sss.pgh.pa.us, jonah.harris@gmail.com, badalex@gmail.com, ktm@rice.edu, mx.cogito@gmail.com, Zdenek.Kotala@sun.com
  Subject: Re: hash index improving v3
  In-Reply-To: <1222175115.4445.344.camel@ebony.2ndQuadrant>

* 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