knngist patch support
in [PgSql]
|
Prev: [HACKERS] knngist patch support
Next: pgsql: Remove old-style VACUUM FULL (which wasknown for a little while
From: Tom Lane on 12 Feb 2010 22:10 Robert Haas <robertmhaas(a)gmail.com> writes: > OK, here's another idea. Let's just add a new column to pg_amop > called amoporderstrategy. If an operator can only be used for one > purpose or the other, we'll set the other value to -1. .... problem for unique index, no? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 12 Feb 2010 22:18 On Fri, Feb 12, 2010 at 10:10 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> OK, here's another idea. Let's just add a new column to pg_amop >> called amoporderstrategy. If an operator can only be used for one >> purpose or the other, we'll set the other value to -1. > > ... problem for unique index, no? Dang. What a pain in the tail. I guess we could make that column nullable, but that's got it's own fair share of problems. Is the only reasonable way to solve this problem a new catalog? That's not tremendously scalable, but it's starting to feel like the only way of solving this problem that doesn't involve massive surgery. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 12 Feb 2010 22:38 Robert Haas <robertmhaas(a)gmail.com> writes: > On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas(a)gmail.com> writes: >>> This is a bit ugly, but one idea that occurs to me is to change >>> amopstrategy from int16 to int32. �Internally, we'll treat the low 16 >>> bits as the strategy number and the high 16 bits as the strategy >>> category, with strategy category 0 being "index search qualifier". >> >> Hm, yeah that would work, but I agree it's ugly. > On further review there's a serious problem with this idea: > pg_amop_opr_fam_index. I think that's soluble though. The reason that index exists is to enforce the rule that an operator can stand in only one relationship to an opfamily. In this design the natural rule would be "one relationship per role", ie, the unique key would become (operator, category, opfamily). However, that does make it even uglier to have category shoehorned in as part of a different field. Back to wanting 5-key syscaches ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 12 Feb 2010 22:39 On Fri, Feb 12, 2010 at 10:38 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> Robert Haas <robertmhaas(a)gmail.com> writes: >>>> This is a bit ugly, but one idea that occurs to me is to change >>>> amopstrategy from int16 to int32. Internally, we'll treat the low 16 >>>> bits as the strategy number and the high 16 bits as the strategy >>>> category, with strategy category 0 being "index search qualifier". >>> >>> Hm, yeah that would work, but I agree it's ugly. > >> On further review there's a serious problem with this idea: >> pg_amop_opr_fam_index. > > I think that's soluble though. The reason that index exists is to > enforce the rule that an operator can stand in only one relationship > to an opfamily. In this design the natural rule would be "one > relationship per role", ie, the unique key would become > (operator, category, opfamily). > > However, that does make it even uglier to have category shoehorned in as > part of a different field. Back to wanting 5-key syscaches ... Sigh. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 13 Feb 2010 15:48
On Sat, Feb 13, 2010 at 3:02 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > What would probably be the recommended solution for backwards-compatible > source code is to convert the actual calls to new style, and then > provide a block of macro definitions along the lines of > > #if CATALOG_VERSION_NO < something > #define SearchSysCache1(...) SearchSysCache(..., 0, 0, 0) > #define SearchSysCache2(...) SearchSysCache(..., 0, 0) > etc > > So that seems okay so far. Where would we put this block of code? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |