Re: Tweaking the planner's heuristics for small/empty tables

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-hackers(at)postgreSQL(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Tweaking the planner's heuristics for small/empty tables
Date: 2011-07-13 14:06:25
Message-ID: 4E1D6011020000250003F295@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Another thing that struck me while looking at the code is that the
> curpages clamp is applied to indexes too, which seems like a
> thinko. A table occupying a few pages wouldn't likely have an
> index as big as the table itself is.

But not zero pages, either.

> So what I'm currently thinking about is a change like this:
>
> if (curpages < 10 &&
> rel->rd_rel->relpages == 0 &&
> !rel->rd_rel->relhassubclass &&
> rel->rd_rel->relkind != RELKIND_INDEX)
> curpages = 10;

Rather than assume ten heap pages and zero index pages, how about
something like:

if (curpages < 10 &&
rel->rd_rel->relpages == 0 &&
!rel->rd_rel->relhassubclass)
curpages = (rel->rd_rel->relkind == RELKIND_INDEX) ? 1 : 10;

> This seems like a safe enough change to apply to 9.1. Going
> forward we might want to change it more, but I think it'd require
> some real-world testing.

I'd be a little nervous about a change which put indexes all the way
to zero without serious testing; otherwise, agreed.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-07-13 14:59:36 Re: Tweaking the planner's heuristics for small/empty tables
Previous Message Heikki Linnakangas 2011-07-13 13:59:39 Re: WIP: Fast GiST index build