Query Hints? No thanks. Data hints?
От | Dimitri Fontaine |
---|---|
Тема | Query Hints? No thanks. Data hints? |
Дата | |
Msg-id | D30BFCFC-98A8-4AF8-9B2D-EBCAF0CC019C@hi-media.com обсуждение исходный текст |
Ответы |
Re: Query Hints? No thanks. Data hints?
|
Список | 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 по дате отправления: