Hi there,
there is a chinese parser for tsearch2 available from
http://code.google.com/p/nlpbamboo/wiki/TSearch2 under BSD license.
It'd be nice to have it for chinese text search configuration we are currently
completely missing, as well as for japanese language ( any guess ?)
Unfortunately,
Hi.
I am sorry to be a very late reaction...
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
From: "Magnus Hagander" <[EMAIL PROTECTED]>
Also, the patch needs error checking. strftime() can fail, and the
multibyte conversion functions can certainly fail. That will need to be
added.
I will propo
Stephen Frost <[EMAIL PROTECTED]> writes:
> ... A case I just realized might be an issue is
> doing a 'select 1 from x;' where you have *no* rights on x, or any
> columns in it, would still get you the rowcount.
Well, if you have table-level select on x, I would expect that to work,
even if your p
2008/11/2 David Rowley <[EMAIL PROTECTED]>:
> Obervations:
>
> Test 3 and 5 did not seem to make use of an index to get a sorted list of
> results. I disabled enable_seqscan but the planner still failed to choose
> index_scan. Is there any reason for this? Perhaps I'm missing something.
> Hitoshi,
Markus, et al,
* Stephen Frost ([EMAIL PROTECTED]) wrote:
> I also wonder if you could use joins or something
> to extract information about columns you're not supposed to have access
> to, or where clauses, etc..
welp, I've done some additional testing and there's good news and bad, I
suppose.
Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
> Sorry, this took way longer than planned.
Beleive me, I understand. :)
> testdb=# GRANT TRUNCATE (single_col) ON test TO malory;
> GRANT
This has been fixed in the attached patch.
> Some privilege regression tests currently fail with your pa
Just a small correction: there should be time::text>>>'prev_time' for the
calculations to be correct:
select *
from (
select (((case when time::text = <<<'prev_time' then *0* else *1*
end)+(<<<'dense_rank')::int4)::text>>>'dense_rank')::int4 as position,
runnerid, time, time::text>>>'prev_
27;ll also
update the commitfest wiki w/ this once it's hit the archives.
Thanks,
Stephen
colprivs_wip.20081101.diff.gz
Description: Binary data
signature.asc
Description: Digital signature
Tom, Robert, Simon,
What, are people just on edge because of the US election?
It looks to me like the commitfest system is going really well. Of
course, we'll see how long it takes to close out 8.4. But I think we're
in much better shape than we were for 8.3. We're even in better shape
to
One of the long-terms goals I'm working toward is wrapping a "wizard"
interface around the tuning guidelines described by
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server now that
those have gone through a fair amount of peer review. Attached is a first
simple version of such a wi
Kris Jurka <[EMAIL PROTECTED]> writes:
> On Thu, 23 Oct 2008, Kris Jurka wrote:
>> The problem with trying to deprecate it is that the vast majority of the
>> backend is still using the old interfaces, so people looking for
>> inspiration for their external modules will likely end up using the ol
> Supposing this is true, one way to prevent that in future
> commitfest-driven releases is to send them back as not ready this
> time, and tell them they'll be 1st in line in the next go-round.
Agreed!
But I'll be as happy as anyone if it doesn't come to that.
...Robert
--
Sent via pgsql-hack
> Without review, how can we determine the true state of a patch? I would
> guess that you haven't done a review of all of them yourself to
> determine that.
No, I'm talking about the comments that were made when submitting the
patch. A few people said things along the lines of "this isn't really
Here is another way to solve "big marathon" without window functions (and
many other kinds of "windowing" queries, especially those that do not
specify "rows preceeding" etc.).
It could be considered as a very dirty hack, however it could give you an
insight on the performance of the "windowed" qu
Bruce Momjian wrote:
KaiGai Kohei wrote:
I've updated my patches, it contains a few bugfixes.
I was wondering why you mention the NSA (U.S. National Security Agency)
in the patch?
NSA is who create SELinux originally IIRC.
Joshua D. Drake
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Sat, Nov 01, 2008 at 04:21:30PM -0400, Robert Haas wrote:
> It looks to me like there are at least half a dozen patches submitted
> in the last week that are pretty half-baked and fall into the category
> of "Let's submit something before the deadline for CommitFest, in the
> hopes of being all
All,
This is my first patch review for PostgreSQL. I did submit a patch last
commit fest (Boyer-Moore) so I feel I should review one this commit fest.
I'm quite new to PostgreSQL so please don't rely on me totally. I'll do my
best. Heikki is also reviewing this patch which makes me feel better.
M
Simon Riggs wrote:
>
> On Sat, 2008-11-01 at 16:21 -0400, Robert Haas wrote:
> > > "Well done"? It seems to me that we are right where we hoped not to be,
> > > ie with a ton of barely-completed (if not self-admitted WIP) patches
> > > dropped on us immediately before feature freeze. Today the c
Emmanuel Cecchet wrote:
> Tom,
>
> > "Well done"? It seems to me that we are right where we hoped not to be,
> > ie with a ton of barely-completed (if not self-admitted WIP) patches
> > dropped on us immediately before feature freeze. Today the commit fest
> > idea is looking like a failure.
> >
On Sat, 2008-11-01 at 16:21 -0400, Robert Haas wrote:
> > "Well done"? It seems to me that we are right where we hoped not to be,
> > ie with a ton of barely-completed (if not self-admitted WIP) patches
> > dropped on us immediately before feature freeze. Today the commit fest
> > idea is lookin
On Mon, Oct 20, 2008 at 4:42 PM, Lawrence, Ramon <[EMAIL PROTECTED]> wrote:
> We propose a patch that improves hybrid hash join's performance for large
> multi-batch joins where the probe relation has skew.
>
> Project name: Histojoin
> Patch file: histojoin_v1.patch
>
> This patch implements the H
KaiGai Kohei wrote:
> I've updated my patches, it contains a few bugfixes.
>
> [1/6]
> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1168.patch
> [2/6]
> http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1168.patch
> [3/6]
> http://sepgsql.googlecode.co
Hello,
I have two concerns regarding the patch:
A) I am not sure if it is good to have a single contention point (pgss->lock
= LWLockAssign()). I guess that would impact scalability, especially on a
multi-cpu systems. I guess the real solution will come when PostgreSQL have
a pool for sql stateme
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On Friday 31 October 2008 17:01:05 Kevin Grittner wrote:
>> (1) Can you compare a literal of the base type?
> No, unless you create additional casts or operators.
>> (2) Can you explicitly cast to the base type?
> There is an implicit AS ASSIGNMEN
On Friday 31 October 2008 17:01:05 Kevin Grittner wrote:
> I notice there's no documentation yet. Do you have a reference to a
> good description of the feature, consistent with your implementation?
Documentation will need to be added, of course, but there isn't really a lot
to describe: you cre
> "Well done"? It seems to me that we are right where we hoped not to be,
> ie with a ton of barely-completed (if not self-admitted WIP) patches
> dropped on us immediately before feature freeze. Today the commit fest
> idea is looking like a failure.
>
> If we actually manage to ship 8.4 within
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Hmm, you're right. I think it can be made to work by storing the *end*
> offset of each chunk. To find the chunk containing offset X, search for
> the first chunk with end_offset > X.
Yeah, that seems like it would work, and it would disentangle u
I finally have a working version. Please have a look at the attached files
including a changed version of gram.y and and automatically created version of
preproc.y. To recreate just run "awk -f parse.awk < gram.y > preproc.y".
Is it okay to change gram.y this way? It does run the regression suite
Tom,
"Well done"? It seems to me that we are right where we hoped not to be,
ie with a ton of barely-completed (if not self-admitted WIP) patches
dropped on us immediately before feature freeze. Today the commit fest
idea is looking like a failure.
If you don't want patches coming at given d
On Sat, 2008-11-01 at 14:22 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Unofficially, well done to everybody that submitted patches in time for
> > Commit Fest. The queue has grown significantly over last few days and
> > it's clear many people have been working very hard
Hi all,
Here is a patch that adds "buffer pool statistics" to the explain analyze
output revealing the number of buffer pages hit at each and every execution
step.
It uses counters from storage/buffer/bufmgr.c (I believe all that counters
are relevant for investigation of query performance).
He
Stephen, what is the status of your efforts?
The latest one I could found is the "colprivs_wip.20080902.diff.gz".
Do you have any updated one?
Snowman told me this week that he was working hard on it -- he declined
to be a reviewer for that reason.
--Josh
--
Sent via pgsql-hackers mailing
Simon Riggs <[EMAIL PROTECTED]> writes:
> Unofficially, well done to everybody that submitted patches in time for
> Commit Fest. The queue has grown significantly over last few days and
> it's clear many people have been working very hard right up to the
> deadline.
"Well done"? It seems to me t
Unofficially, well done to everybody that submitted patches in time for
Commit Fest. The queue has grown significantly over last few days and
it's clear many people have been working very hard right up to the
deadline.
Depending upon how you count it there are around 5 multi-month mega
patches,
Greg Stark <[EMAIL PROTECTED]> writes:
> This isn't the same thing as allowing RETURNING inside subqueries,
> right?
Right. You could fairly easily get that now by wrapping your RETURNING
query into a SQL function ... but I'm not sure that we want to advertise
that heavily, because the question
On Sat, 2008-11-01 at 13:23 -0400, Robert Haas wrote:
> > Can you test whether using the buffer access strategy is a win or a
> > loss? Most of that gain is probably coming from the reduction in
> > pinning.
>
> --PATCHED--
> Time: 13869.724 ms (median)
> --PATCHED with BAS disabled--
> Time: 14
> Can you test whether using the buffer access strategy is a win or a
> loss? Most of that gain is probably coming from the reduction in
> pinning.
Patch resnapped to HEAD, with straightforward adjustments to
compensate for Heikki's changes to the ReadBuffer interface. See
attached.
New testing
On Sat, 2008-11-01 at 15:18 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2008-10-31 at 15:05 +, Heikki Linnakangas wrote:
> >> Log Message:
> >> ---
> >> Unite ReadBufferWithFork, ReadBufferWithStrategy, and ZeroOrReadBuffer
> >> functions into one ReadBufferExtend
On Sat, 2008-11-01 at 06:13 +0200, Hannu Krosing wrote:
> attached is a patch which enables plpython to recognize function with
> multiple OUT params as returning a record
Overrides previous patch.
Fixed some bugs, added regression tests.
> This version is quite rough, though passes tests here.
This isn't the same thing as allowing RETURNING inside subqueries,
right?
greg
On 31 Oct 2008, at 07:37 PM, [EMAIL PROTECTED] (Tom Lane) wrote:
Log Message:
---
Allow SQL-language functions to return the output of an INSERT/
UPDATE/DELETE
RETURNING clause, not just a SELECT as form
40 matches
Mail list logo
