Re: [HACKERS] Cost model for parallel CREATE INDEX - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Cost model for parallel CREATE INDEX
Date
Msg-id 20170304140004.GF9812@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Cost model for parallel CREATE INDEX  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: [HACKERS] Cost model for parallel CREATE INDEX  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Peter,

* Peter Geoghegan (pg@bowt.ie) wrote:
> On Sat, Mar 4, 2017 at 12:50 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > If the result of
> > compute_parallel_workers() based on min_parallel_table_scan_size is
> > smaller, then use that value instead.  I must be confused, because I
> > actually though that was the exact algorithm you were describing, and
> > it sounded good to me.
>
> It is, but I was using that with index size, not table size. I can
> change it to be table size, based on what you said. But the workMem
> related cap, which probably won't end up being applied all that often
> in practice, *should* still do something with projected index size,
> since that really is what we're sorting, which could be very different
> (e.g. with partial indexes).

Isn't that always going to be very different, unless you're creating a
single index across every column in the table..?  Or perhaps I've
misunderstood what you're comparing as being 'very different' in your
last sentence.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Julian Markwort
Date:
Subject: Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans
Next
From: David Steele
Date:
Subject: Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional