Re: Hints WAS: Index Tuning Features

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Mark Woodward <pgsql(at)mohawksoft(dot)com>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jaime Casanova <systemguards(at)gmail(dot)com>
Subject: Re: Hints WAS: Index Tuning Features
Date: 2006-10-12 21:23:46
Message-ID: 87vempkz31.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:

> Which could then be used by the planner. Or more directly:
>
> CREATE HISTOGRAM FOR FUNCTION verify_pk_signature(documenent)
> AS ( true = 99, false = 1 );
>
> (Perhaps DECLARE is the better phrase?).

Except that the distribution is a property of the values you're passing it,
not the function itself. In theory verify_pk_signature() returns false for
99.999...% of its inputs. But of course unless you have a black hat or
hardware problems you're not going to ever pass it any input that makes it
return false.

The query may be a routine session cookie check where it will virtually always
return true, or it may be a DBA running an ad-hoc query to check suspicious
records for invalid data. It may even be the same query from the same object
method being called from different call sites in the application.

I'm not saying the above isn't a good idea though. I rather like it actually.
But the point of my example originally was specifically to show how at least
sometimes the *only* place the knowledge of the data distribution lies is in
the programmer's head.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-10-12 21:26:02 Re: On status data and summaries
Previous Message Bucky Jordan 2006-10-12 21:19:29 Re: [HACKERS] Hints proposal