Tom Lane wrote:
I'm kind of leaning to the separate-tally method and abandoning the
assumption that the identities hold. I'm not wedded to the idea
though. Any thoughts?
That seems like the best approach to me. Like the scan/fetch counters,
n_tup_ins and n_tup_del represent work done
On Fri, 25 May 2007, Hitoshi Harada wrote:
Hi,
I was walking through GIN am source code these days, and found that it has
only posting lists but no positions related those.
The reason I was doing that is, to try to implement n-gram text search index
on GIN for myself. As you know Japanese is
FYI, Tatsuo uses tsearch2 for indexing japanese documents. But I agree,
n-gram index would be more universal for asian languages.
Yeah, I know, but in tsearch2 for japanese sample you must use external
morphological analysis libraries to separate words. It is powerful but I
need more lightweight
The attached script works in REL8_2_STABLE, but crashes current head
with a SEGV. It somehow manages to have the cheapest path being a NULL
pointer instead of a dummy Append.
Jan
--
#==#
# It's easier to get forgiveness for
On Sat, 2007-05-26 at 11:19 -0400, Jan Wieck wrote:
The attached script works in REL8_2_STABLE, but crashes current head
with a SEGV. It somehow manages to have the cheapest path being a NULL
pointer instead of a dummy Append.
Just starting to look at this now.
--
Simon Riggs
Jan Wieck [EMAIL PROTECTED] writes:
The attached script works in REL8_2_STABLE, but crashes current head
with a SEGV.
Looks like I broke it :-(. Fixed, thanks for the test case.
regards, tom lane
---(end of
On 5/25/07, Bernd Helmle [EMAIL PROTECTED] wrote:
--On Freitag, Mai 25, 2007 00:02:06 + Jaime Casanova
[EMAIL PROTECTED] wrote:
sounds good. can we see the new patch?
Attached tablespace.c.diff shows my current changes to use an OID lookup
list.
on second thought, what happens if
I think this patch needs to be revisited in the light of the work I just
did to make pgstats correctly track the effects of aborted transactions.
It seems fairly likely to me that most of the problem you were seeing
was actually due to that stupidity, and not to race conditions between
VACUUM and
Tom Lane wrote:
This means that a table could easily be full of dead tuples from failed
transactions, and yet autovacuum won't do a thing because it doesn't
know there are any. Perhaps this explains some of the reports we've
heard of tables bloating despite having autovac on.
I think this is
The buildfarm appears to be failing after the recent pgstat patch.
The failure seems to be caused by this failed assertion, which appears to
occur fairly consistently in the ECPG tests, in the postmaster log:
TRAP: FailedAssertion(!(entry-trans == 0L), File: pgstat.c, Line: 696)
--
Disco is
Jeremy Drake [EMAIL PROTECTED] writes:
The buildfarm appears to be failing after the recent pgstat patch.
Yeah, just saw that myself. Fixed the backend-side problem, but it
would be interesting to find out what ECPG is doing that wasn't exposed
by the core regression tests ... maybe we need
11 matches
Mail list logo
