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

Re: Bugs/slowness inserting and indexing cubes

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Jay Levitt <jay(dot)levitt(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Bugs/slowness inserting and indexing cubes
Date: 2012-02-15 14:40:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Feb 15, 2012 at 4:26 PM, Heikki Linnakangas <
heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

> Actually, I think it made sense to simply do nothing if the buffer doesn't
> exist. The algorithm doesn't require that all the buffers must exist at all
> times. It is quite accidental that whenever we call
> gistRelocateBuildBuffersOnSpli**t(), the page must already have its
> buffer created (and as we found out, the assumption doesn't hold after a
> root split, anyway). Also, we talked earlier that it would be good to
> destroy buffers that become completely empty, to save memory. If we do
> that, we'd have to remove that check anyway.
> So, I think we should go with your original fix and simply do nothing in
> gistRelocateBuildBuffersOnSpli**t() if the page doesn't have a buffer.
> Moreover, if the page has a buffer but it's empty,
> gistRelocateBuildBuffersOnSpli**t() doesn't need to create buffers for
> the new sibling pages. In the final emptying phase, that's a waste of time,
> the buffers we create will never be used, and even before that I think it's
> better to create the buffers lazily.

I agree.

With best regards,
Alexander Korotkov.

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-02-15 14:59:50
Subject: Re: [trivial patch] typo in doc/src/sgml/sepgsql.sgml
Previous:From: Peter GeogheganDate: 2012-02-15 13:29:14
Subject: Re: Progress on fast path sorting, btree index creation time

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