e stemming,
tokenization rules, etc. If the language rules allow this to match
"larger house" or "large-house", then a phrase restriction should,
too. It's also painful when the FTS column is an aggregate of several
other columns (eg. title and body), since a LIKE match need
on, Nov 1, 2010 at 4:35 PM, Glenn Maynard wrote:
> How are adjacent word searches handled with FTS? tsquery doesn't do
> this, so I assume this has to be done as a separate filter step, eg.:
>
> # "large house" sales
> SELECT * FROM data WHERE fts @@ to_tsquery('
2010/12/19 Oleg Bartunov :
> You might be interested in http://www.sai.msu.su/~megera/wiki/2009-08-12
Thanks, that looks pretty much like what I had in mind. Hopefully
that'll get merged for 9.0+1; phrases are a major part of all text
searches.
--
Glenn Maynard
--
Sent via pgsql
lse too). Write
> (-2147483648)::int4 instead.
>
That's surprising enough that it might be worth generating a warning if the
typecasting operator is used on a mathmatical expression--"a -
b::int4"--rather than a single value (eg. "(a - b)::int4" or "f()::int4").
I don't know the grammar to know if that fits.
--
Glenn Maynard
ces of this would be very
helpful.
--
Glenn Maynard
sion you want, and the migrations accumulate. However, it can handle
whatever arbitrary steps are needed to update a database, and I don't need
to test updates from every version to every other version.
--
Glenn Maynard
migrating to 2 is
extremely hard. I suspect you'd need to snapshot the schema at each version
where these are needed to update incrementally, rather than always trying to
convert directly to the current version--maybe you already do that.
Anyhow, just some thoughts based on my own experience with database
updates--good luck.
--
Glenn Maynard
sure that branches don't collide with each other.) Databases
migrate straightforwardly after the merge, regardless of whether they were
migrated to trunk or to the branch.
--
Glenn Maynard
> performance isn't so important any more. :)
>
That's often perfectly fine, with read-heavy, single-writer workloads.
I definitely wish there was a way to create indexes to track counters on
various types of queries, even if it eliminates write concurrency on
affected writes. Doi
On Mon, Mar 7, 2011 at 1:13 PM, Merlin Moncure wrote:
> On Sun, Mar 6, 2011 at 2:57 PM, Glenn Maynard wrote:
> > That's often perfectly fine, with read-heavy, single-writer workloads.
> >
> > I definitely wish there was a way to create indexes to track counters on
&g
matching rows for each (user, day)
tuple--which is ultimately what I'm doing manually with triggers. Of
course, it would have a significant cost, in some combination of complexity,
index size and write concurrency, and couldn't be the default behavior for
an index.
--
Glenn Maynard
ot timestamptz) because of time zone dependency. Any ad
> hoc caching would also have the same problem, if users from different
> time zones were hitting the cache -- they could get the wrong answer.
>
It's designed with this in mind.
--
Glenn Maynard
ing aggregates.
> And it looks like you already have it with your triggers.
>
With cumbersome, awkward triggers, yes.
--
Glenn Maynard
rth, 0xe3273a in the dump is within the string
"'x':17" where x is \xe3, the first byte of the UTF-8 representation of
U+30FC "ー". (If this sounds like a known or fixed problem I'd be interested
to know, but this sort of problem in a minor subsystem like FTS shouldn't be
able to silently break backups in the first place.)
--
Glenn Maynard
14 matches
Mail list logo
