pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: brendan.curran@gmail.com
Cc: Jim C. Nasby <jim@nasby.net>
Cc: g@nasby.net, Pg Performance list <pgsql-performance@postgresql.org>
Subject: Re: Scrub one large table against another
Date: Thu, 12 Oct 2006 14:25:09 -0400
Message-ID: <14924.1160677509@sss.pgh.pa.us> (raw)
In-Reply-To: <452E83D0.5060309@gmail.com>
References: <452C1437.9040709@gmail.com>
	<13451.1160518445@sss.pgh.pa.us>
	<452C208C.5010603@gmail.com>
	<13912.1160520427@sss.pgh.pa.us>
	<452C30CA.2070801@gmail.com>
	<15751.1160535019@sss.pgh.pa.us>
	<452D2195.8010907@gmail.com>
	<20061011205251.GR13487@nasby.net>
	<452E83D0.5060309@gmail.com>

Brendan Curran <brendan.curran@gmail.com> writes:
> I'll tack up a note to the online documentation letting people know so
> that it's a little more explicitly clear that when you choose IN on
> data that isn't explicitly unique (to the planner i.e.  post-analyze)
> you get the baggage of a forced unique whether you need it or not. Or
> perhaps someone that knows the internals of the planner a little
> better than me should put some info up regarding that?

You get a forced unique step, period --- the planner doesn't try to
shortcut on the basis of noticing a relevant unique constraint.
We have some plan techniques that might look like they are not checking
uniqueness (eg, an "IN Join") but they really are.

This is an example of what I was talking about just a minute ago, about
not wanting to rely on constraints that could go away while the plan is
still potentially usable.  It's certainly something that we should look
at adding as soon as the plan-invalidation infrastructure is there to
make it safe to do.

			regards, tom lane



view thread (11+ messages)

Message-ID: <14924.1160677509@sss.pgh.pa.us>
Permalink:  ../14924.1160677509@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/14924.1160677509@sss.pgh.pa.us

 · 

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: tgl@sss.pgh.pa.us, brendan.curran@gmail.com, jim@nasby.net
  Subject: Re: Scrub one large table against another
  In-Reply-To: <14924.1160677509@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