Query Hints? No thanks. Data hints? - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Query Hints? No thanks. Data hints?
Date
Msg-id D30BFCFC-98A8-4AF8-9B2D-EBCAF0CC019C@hi-media.com
Whole thread Raw
Responses Re: Query Hints? No thanks. Data hints?
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi -hackers,

In another thread about "GUC parameter cursors_tuple_fraction", the  
debate seems to drift onto query hints. About which the consensus here  
is pretty clear and strong, no query hints in PostgreSQL, thanks, or  
we're never gonna have a perfect generic planner.

IIRC, I've read here in the past some attempts to begin a proposal on  
the topic of data hints, allowing the user to describe his data in a  
way ANALYZE can't figure out by itself, as e.g. "this column value is  
tied to this other column value in this way".
This could be a materialized column, mutual-exclusive NOT NULLs, or  
any multi-columns relationships, as well as "this table is a fact  
table", etc.

What do you -hackers think about such a plan: - assess cases where the planner is failing short of good statistics
 - assess data properties SQL does not give us but would be of  
interrest   to internals, and at the same time not so difficult to know about  
by DBAs
 - based on this, prepare a descriptive language of some sort tying  
this all in
 - implement it in a good way ;)

I'm thinking we could have a new set of commands to tell PostgreSQL  
some "high-level" facts about the data, e.g. "there's a injective  
function such as f(t.colA) = t.colB" or any useful thing to be found  
in the firsts proposed step.

Is there a chance we're gonna improve the planner this way? And answer  
Simon's (and many others here and there, -performance etc) concerns?

HTH, regards,
- --
dim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkgeEjoACgkQlBXRlnbh1bnlHwCfcHL5uOlCpptekwLBMp+E9kUn
4roAoMfwdITByHtxCi35l9jDCTSFw2Ho
=whVn
-----END PGP SIGNATURE-----


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Next
From: "Zeugswetter Andreas OSB sIT"
Date:
Subject: Re: statement timeout vs dump/restore