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
ing aggregates.
> And it looks like you already have it with your triggers.
>
With cumbersome, awkward triggers, yes.
--
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
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
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
> 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
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
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
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
ces of this would be very
helpful.
--
Glenn Maynard
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
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
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('
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
14 matches
Mail list logo
