From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Mladen Gogala <mladen.gogala@vmsinfo.com>
Subject: Re: anti-join chosen even when slower than old plan
Date: Thu, 11 Nov 2010 14:41:50 -0500
Message-ID: <19896.1289504510@sss.pgh.pa.us> (raw)
In-Reply-To: <4CDBEC8B02000025000375CF@gw.wicourts.gov>
References: <4CD9663502000025000374B1@gw.wicourts.gov>
<20961.1289347680@sss.pgh.pa.us>
<4CDA62C60200002500037512@gw.wicourts.gov>
<AANLkTi=eNXKEBo5dXJDd4+aHhfmkibH++fqjj12+DA3o@mail.gmail.com>
<4CDACBBF020000250003755B@gw.wicourts.gov>
<4CDB7BAA.7020506@vmsinfo.com>
<4CDBB0A40200002500037571@gw.wicourts.gov>
<AANLkTi=dzhRTTNm1LkyNCAC5+PWbp1jWtKFh4T1Bu4nj@mail.gmail.com>
<18450.1289499783@sss.pgh.pa.us>
<18450.1289499783@sss.pgh.pa.us>
<19088.1289501929@sss.pgh.pa.us>
<4CDBEC8B02000025000375CF@gw.wicourts.gov>
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Besides the "fully-scanned object size relative to relation size
> costing adjustment" idea, the only one which seemed to be likely to
> be useful for this sort of issue was the "costing factors by user
> ID" idea -- the interactive queries hitting the well-cached portion
> of the tables are run through a read-only user ID, while the weekly
> maintenance scripts (obviously) are not. With the settings I
> initially had assigned to the cluster the maintenance scripts would
> never have seen this issue; it was tuning to resolve end-user
> complaints of slowness in the interactive queries which set up the
> conditions for failure, and if I'd had per-user settings, I probably
> would have (and definitely *should* have) used them.
Erm ... you can in fact do "ALTER USER SET random_page_cost" today.
As long as the settings are GUC parameters we have quite a lot of
flexibility about how to control them. This gets back to my earlier
point that our current form of per-relation properties (reloptions) is
considerably less flexible than a GUC. I think that if we create any
strong planner dependence on such properties, we're going to end up
needing to be able to set them in all the same ways you can set a GUC.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, Kevin.Grittner@wicourts.gov, robertmhaas@gmail.com, mladen.gogala@vmsinfo.com
Subject: Re: anti-join chosen even when slower than old plan
In-Reply-To: <19896.1289504510@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox