pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Kevin Grittner <Kevin.Grittner@wicourts.gov>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-performance@postgresql.org
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: anti-join chosen even when slower than old plan
Date: Wed, 10 Nov 2010 16:43:43 -0600
Message-ID: <4CDACBBF020000250003755B@gw.wicourts.gov> (raw)
In-Reply-To: <AANLkTi=eNXKEBo5dXJDd4+aHhfmkibH++fqjj12+DA3o@mail.gmail.com>
References: <4CD9663502000025000374B1@gw.wicourts.gov>
	<20961.1289347680@sss.pgh.pa.us>
	<4CDA62C60200002500037512@gw.wicourts.gov>
	<AANLkTi=eNXKEBo5dXJDd4+aHhfmkibH++fqjj12+DA3o@mail.gmail.com>

Robert Haas <robertmhaas@gmail.com> wrote:
 
> Wow.  That's fascinating, and if you don't mind, I might mention
> this potential problem in a future talk at some point.
 
I don't mind at all.
 
> For example, in your case, it would be sufficient to estimate the
> amount of data that a given query is going to grovel through and
> then applying some heuristic to choose values for random_page_cost
> and seq_page_cost based on the ratio of that value to, I don't
> know, effective_cache_size.
 
That's where my day-dreams on the topic have been starting.
 
> Unfortunately, to know how much data we're going to grovel
> through, we need to know the plan; and to decide on the right
> plan, we need to know how much data we're going to grovel through.
 
And that's where they've been ending.
 
The only half-sane answer I've thought of is to apply a different
cost to full-table or full-index scans based on the ratio with
effective cache size.  A higher cost for such scans is something
which I've already postulated might be worthwhile for SSI, because
of the increased risk of rw-conflicts which could ultimately
contribute to serialization failures -- to attempt to model, at
least in some crude way, the costs associated with transaction
retry.
 
-Kevin



view thread (62+ messages)  latest in thread

Message-ID: <4CDACBBF020000250003755B@gw.wicourts.gov>
Permalink:  ../4CDACBBF020000250003755B@gw.wicourts.gov/
Also on:    postgresql.org/message-id/4CDACBBF020000250003755B@gw.wicourts.gov

 · 

reply

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: Kevin.Grittner@wicourts.gov, robertmhaas@gmail.com, tgl@sss.pgh.pa.us
  Subject: Re: anti-join chosen even when slower than old plan
  In-Reply-To: <4CDACBBF020000250003755B@gw.wicourts.gov>

* 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