OK, I think what I will do is create a new BIGINT column with AUTO_INCREMENT and use that as my primary key, and just pass that column along with my VARCHAR columns to FT_CREATE_INDEX. Thank you for the help.
On Friday, March 8, 2013 8:42:30 AM UTC-5, Noel Grandin wrote: > > No, it will add all of the columns to the index. > > On 2013-03-08 15:31, Zach wrote: > > The BINARY column is always 20 bytes (a SHA1 hash). Can I assume > that FT_CREATE_INDEX will not try to tokenize this column if I pass NULL in > the third parameter? Like I said, I need this column to be present in the > indexed table, so I can properly JOIN it on the original table, but I don't > want it to try indexing a SHA1 hash (i.e. try to find tokens that may > randomly exist in the hash). > > On Friday, March 8, 2013 1:18:44 AM UTC-5, Thomas Mueller wrote: >> >> Hi, >> >> It's absolutely no problem to use a primary key of type binary. It's >> not inefficient if the data is small (even thought bigint is faster). >> >> For fulltext indexing, it makes sense to only index those columns that >> you are interested in (CLOB columns mainly). >> >> Regards, >> Thomas >> >> >> >> On Fri, Mar 8, 2013 at 2:52 AM, Ryan How <[email protected]> wrote: >> >>> I think you've figured it out yourself. You'd have to have a pretty >>> compelling use case to use a BINARY column for a PK I think. It would be >>> very inefficient! Unless it is a really small BINARY column. >>> >>> >>> On 7/03/2013 10:23 PM, Zach wrote: >>> >>>> I have a table with a BINARY column that acts as a primary key. I want >>>> to index this table for searching, but I obviously don't want it to index >>>> this column. When I call "FT_CREATE_INDEX('PUBLIC', 'TEST', NULL)" on the >>>> table, will it ignore the column because it's BINARY, or will it try >>>> indexing it? >>>> >>>> I know I can specify a comma-delimited list of columns in the third >>>> parameter. However, since this BINARY column acts as a primary key, I >>>> think >>>> I need it in the indexed table so I can properly JOIN it to the original >>>> table. >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "H2 Database" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/h2-database?hl=en. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "H2 Database" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/h2-database?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> -- > You received this message because you are subscribed to the Google Groups > "H2 Database" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected]<javascript:> > . > Visit this group at http://groups.google.com/group/h2-database?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
