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

Re: Progress on fast path sorting, btree index creation time

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Progress on fast path sorting, btree index creation time
Date: 2011-12-30 21:02:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Dec 30, 2011 at 2:30 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> On 30 December 2011 19:46, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> On Thu, Dec 29, 2011 at 8:03 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
>>> * A spreadsheet that shows the results of re-running my earlier heap
>>> tuple sorting benchmark with this new patch. The improvement in the
>>> query that orders by 2 columns is all that is pertinent there, when
>>> considering the value of (1) and the sense in standing still for
>>> controversy A.
>>> * A spreadsheet that shows the difference in index creation times,
>>> generated with the help of the new python script.
>> very nice.  let me save everyone the effort of opening his
>> spreadsheets (which by the way both show 'HEAD/unoptimized' --
>> probably not what you meant): he's showing a consistent ~50% reduction
>> in running time of sort driven queries -- that's money.
> Sorry, I think you may have misinterpreted the results, which is my
> fault - I introduced a formatting error. In the case of the "btree"
> spreadsheet, the first query on each sheet should be "create index
> test on orderlines (prod_id);", and not "select * from orderlines
> order by prod_id". The idea is to compare the results from each set of
> binaries across pages of the spreadsheet (note that there are two
> tabs). You should not compare anything between the two spreadsheets.
> Revised btree results attached. The heap results that I posted do not
> have any formatting errors, so they have not been revised.

right-- my bad. still, that's 31-37% -- still pretty nice.


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-12-30 22:20:20
Subject: Re: Should I implement DROP INDEX CONCURRENTLY?
Previous:From: Peter GeogheganDate: 2011-12-30 20:30:05
Subject: Re: Progress on fast path sorting, btree index creation time

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