On 20.02.2012 10:54, Alexander Korotkov wrote:
On Wed, Feb 15, 2012 at 7:28 PM, Tom Lane wrote:
Alexander Korotkov writes:
On Wed, Feb 15, 2012 at 4:26 PM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
So, I think we should go with your original fix and simply do nothing
On Wed, Feb 15, 2012 at 7:28 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Wed, Feb 15, 2012 at 4:26 PM, Heikki Linnakangas <
> > heikki.linnakan...@enterprisedb.com> wrote:
> >> So, I think we should go with your original fix and simply do nothing in
> >> gistRelocateBuildBuffersOnSpl
Alexander Korotkov writes:
> On Wed, Feb 15, 2012 at 4:26 PM, Heikki Linnakangas <
> heikki.linnakan...@enterprisedb.com> wrote:
>> 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.
> I agree.
OK, I
On Wed, Feb 15, 2012 at 4:26 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.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
On 15.02.2012 10:18, Alexander Korotkov wrote:
On Wed, Feb 15, 2012 at 2:54 AM, Tom Lane wrote:
Alexander Korotkov writes:
ITSM, I found the problem. This piece of code is triggering an error. It
assumes each page of corresponding to have initialized buffer. That
should
be true because we'
On Wed, Feb 15, 2012 at 2:54 AM, Tom Lane wrote:
> Alexander Korotkov writes:
> > ITSM, I found the problem. This piece of code is triggering an error. It
> > assumes each page of corresponding to have initialized buffer. That
> should
> > be true because we're inserting index tuples from up to
Alexander Korotkov writes:
> ITSM, I found the problem. This piece of code is triggering an error. It
> assumes each page of corresponding to have initialized buffer. That should
> be true because we're inserting index tuples from up to down while
> splits propagate from down to up.
> But this ass
ITSM, I found the problem. This piece of code is triggering an error. It
assumes each page of corresponding to have initialized buffer. That should
be true because we're inserting index tuples from up to down while
splits propagate from down to up.
if (!found)
{
/*
* Node buffer should exist at t
Robert Haas wrote:
On Mon, Feb 13, 2012 at 7:45 AM, Robert Haas wrote:
On Thu, Feb 9, 2012 at 3:37 PM, Jay Levitt wrote:
So my pre-built 9.1.2 takes 434s, my source-built 9.2 takes 509s, and
(probably both of our) 9.1-HEAD takes 1918s... is that something to worry
about, and if so, are there
On Mon, Feb 13, 2012 at 7:45 AM, Robert Haas wrote:
> On Thu, Feb 9, 2012 at 3:37 PM, Jay Levitt wrote:
>> So my pre-built 9.1.2 takes 434s, my source-built 9.2 takes 509s, and
>> (probably both of our) 9.1-HEAD takes 1918s... is that something to worry
>> about, and if so, are there any tests I
On Thu, Feb 9, 2012 at 3:37 PM, Jay Levitt wrote:
> So my pre-built 9.1.2 takes 434s, my source-built 9.2 takes 509s, and
> (probably both of our) 9.1-HEAD takes 1918s... is that something to worry
> about, and if so, are there any tests I can run to assist? That bug doesn't
> affect me personally
Tom Lane wrote:
Jay Levitt writes:
[Posted at Andres's request]
TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
various builds.
1. In 9.1.2, inserting 10x rows takes 19x the time.
- 9.1-HEAD and 9.2 "fix" this; it now slows down linearly
- but: 10s> 8s
Jay Levitt writes:
> [Posted at Andres's request]
> TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
> various builds.
> 1. In 9.1.2, inserting 10x rows takes 19x the time.
> - 9.1-HEAD and 9.2 "fix" this; it now slows down linearly
> - but: 10s > 8s > 5s!
>
Robert Haas writes:
> I guess. I think the compelling reason to do ambuildempty first is
> that it's fast. So might as well. I think you'e just going to end up
> hard-wiring the assumption that ambuild happens before ambuildempty,
Well, no, because I'm proposing that both functions throw this
On Tue, Feb 7, 2012 at 11:26 PM, Jay Levitt wrote:
> [*] psql:slowcube.sql:20: ERROR: node buffer of page being split (121550)
> does not exist
>
This looks like a bug in buffering GiST index build I've implemented during
my GSoC 2011 project. It looks especially strange with following setting:
On Wed, Feb 8, 2012 at 2:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane wrote:
>>> ISTM there are two ways we could fix this:
>>>
>>> 1. Introduce a duplicative test at the start of gistbuild().
>>>
>>> 2. Rearrange the order of operations in index_build
Robert Haas writes:
> On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane wrote:
>> ISTM there are two ways we could fix this:
>>
>> 1. Introduce a duplicative test at the start of gistbuild().
>>
>> 2. Rearrange the order of operations in index_build() so that the init
>> fork is made first.
>>
>> Both
On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane wrote:
> Jay Levitt writes:
>> [Posted at Andres's request]
>> TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
>> various builds.
>
> Not sure yet about most of these, but I know the reason for this one:
>
>> 2. In both 9.1 and
Jay Levitt writes:
> [Posted at Andres's request]
> TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
> various builds.
Not sure yet about most of these, but I know the reason for this one:
> 2. In both 9.1 and 9.2, there is a long delay before CREATE INDEX realizes
Jay Levitt wrote:
[Posted at Andres's request]
TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
various builds.
And I bet you'll want the test script... sigh. attached.
\c postgres
drop database if exists slowcube;
create database slowcube;
\c slowcube
\timing
crea
[Posted at Andres's request]
TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
various builds.
NOTABLE PROBLEMS
1. In 9.1.2, inserting 10x rows takes 19x the time.
- 9.1-HEAD and 9.2 "fix" this; it now slows down linearly
- but: 10s > 8s > 5s!
- but: compar
21 matches
Mail list logo
