Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-03-02 Thread Heikki Linnakangas
On 20.02.2012 10:54, Alexander Korotkov wrote: On Wed, Feb 15, 2012 at 7:28 PM, Tom Lanet...@sss.pgh.pa.us wrote: Alexander Korotkovaekorot...@gmail.com writes: On Wed, Feb 15, 2012 at 4:26 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: So, I think we should go with

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-20 Thread Alexander Korotkov
On Wed, Feb 15, 2012 at 7:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Alexander Korotkov aekorot...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-15 Thread Alexander Korotkov
On Wed, Feb 15, 2012 at 2:54 AM, Tom Lane t...@sss.pgh.pa.us wrote: Alexander Korotkov aekorot...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-15 Thread Heikki Linnakangas
On 15.02.2012 10:18, Alexander Korotkov wrote: On Wed, Feb 15, 2012 at 2:54 AM, Tom Lanet...@sss.pgh.pa.us wrote: Alexander Korotkovaekorot...@gmail.com writes: ITSM, I found the problem. This piece of code is triggering an error. It assumes each page of corresponding to have initialized

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-15 Thread Alexander Korotkov
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 we

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-15 Thread Tom Lane
Alexander Korotkov aekorot...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-14 Thread Alexander Korotkov
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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-14 Thread Tom Lane
Alexander Korotkov aekorot...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-13 Thread Robert Haas
On Thu, Feb 9, 2012 at 3:37 PM, Jay Levitt jay.lev...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-13 Thread Robert Haas
On Mon, Feb 13, 2012 at 7:45 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Feb 9, 2012 at 3:37 PM, Jay Levitt jay.lev...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-13 Thread Jay Levitt
Robert Haas wrote: On Mon, Feb 13, 2012 at 7:45 AM, Robert Haasrobertmh...@gmail.com wrote: On Thu, Feb 9, 2012 at 3:37 PM, Jay Levittjay.lev...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-09 Thread Jay Levitt
Tom Lane wrote: Jay Levittjay.lev...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-08 Thread Tom Lane
Jay Levitt jay.lev...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-08 Thread Robert Haas
On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jay Levitt jay.lev...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-08 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-08 Thread Robert Haas
On Wed, Feb 8, 2012 at 2:38 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us wrote: ISTM there are two ways we could fix this: 1. Introduce a duplicative test at the start of gistbuild(). 2.

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-08 Thread Alexander Korotkov
On Tue, Feb 7, 2012 at 11:26 PM, Jay Levitt jay.lev...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-08 Thread Tom Lane
Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-08 Thread Tom Lane
Jay Levitt jay.lev...@gmail.com 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

Re: [HACKERS] Bugs/slowness inserting and indexing cubes

2012-02-07 Thread Jay Levitt
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