I have attached a patch that emits parts of a host token, a url token,
an email token and a file token. Further, it makes sure that a
host/url/email/file token and the first part-token are at the same
position in tsvector.
The two major changes are:
1. Tokenization changes: The patch exploits
On 1 September 2010 06:45, David E. Wheeler da...@kineticode.com wrote:
The aggregate docs say:
The first form of aggregate expression invokes the aggregate across all
input rows for which the given expression(s) yield non-null values.
(Actually, it is up to the aggregate function whether
On Aug 31, 2010, at 11:56 PM, Thom Brown wrote:
The first form of aggregate expression invokes the aggregate across all
input rows for which the given expression(s) yield non-null values.
(Actually, it is up to the aggregate function whether to ignore null values
or not — but all the
On 31/08/10 15:47, Fujii Masao wrote:
On Fri, Aug 27, 2010 at 4:39 PM, Fujii Masaomasao.fu...@gmail.com wrote:
/*
* XXX: Should we invent an API to wait for data coming from the
* client connection too? It's not critical, but we could then
* eliminate the timeout altogether and go to
2010/9/1 David E. Wheeler da...@kineticode.com:
The aggregate docs say:
The first form of aggregate expression invokes the aggregate across all
input rows for which the given expression(s) yield non-null values.
(Actually, it is up to the aggregate function whether to ignore null values
On Wed, Sep 1, 2010 at 2:33 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Once we're done with that, all the big questions are still left.
Yeah, let's discuss about those topics :)
How to configure it?
Before discussing about that, we should determine whether registering
On 1 September 2010 07:56, Thom Brown t...@linux.com wrote:
On 1 September 2010 06:45, David E. Wheeler da...@kineticode.com wrote:
The aggregate docs say:
The first form of aggregate expression invokes the aggregate across all
input rows for which the given expression(s) yield non-null
(2010/07/21 19:35), KaiGai Kohei wrote:
(2010/07/21 19:26), Robert Haas wrote:
2010/7/21 KaiGai Koheikai...@ak.jp.nec.com:
On the other hand, if it's enough from a performance
point of view to review and mark only a few built-in functions like
index operators, maybe it's ok.
I also think it
-20100901.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/09/10 10:53, Fujii Masao wrote:
Before discussing about that, we should determine whether registering
standbys in master is really required. It affects configuration a lot.
Heikki thinks that it's required, but I'm still unclear about why and
how.
Why do standbys need to be registered in
On Wed, Sep 1, 2010 at 02:33, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 31, 2010 at 5:07 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Aug 31, 2010 at 19:46, Magnus Hagander mag...@hagander.net wrote:
On Tue, Aug 31, 2010 at 19:44, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus
Hi,
we are experimenting with modifying table partitioning
so the ORDER BY clause can be pushed down to
child nodes on the grounds that:
1. smaller datasets are faster to sort, e.g. two datasets that almost
spill out to disk are faster to sort in memory and later merge them
than the union
Boszormenyi Zoltan z...@cybertec.at writes:
we are experimenting with modifying table partitioning
so the ORDER BY clause can be pushed down to
child nodes on the grounds that:
This is really premature, and anything you do along those lines now will
probably never get committed. The problem
2010/9/1 Boszormenyi Zoltan z...@cybertec.at:
we are experimenting with modifying table partitioning
so the ORDER BY clause can be pushed down to
child nodes on the grounds that:
1. smaller datasets are faster to sort, e.g. two datasets that almost
spill out to disk are faster to sort in
On Sep 1, 2010, at 4:10 PM, Tom Lane wrote:
Boszormenyi Zoltan z...@cybertec.at writes:
we are experimenting with modifying table partitioning
so the ORDER BY clause can be pushed down to
child nodes on the grounds that:
This is really premature, and anything you do along those lines now
1. The statement
UPDATE table SET fld1 = :input1
WHERE CURRENT OF :curname
RETURNING id + :input2;
is transformed into
UPDATE table SET fld1 = $1
WHERE CURRENT OF $0
RETURNING id + $2;
and the $0 is past $1. The current code cannot deal with such
On 30/08/10 15:14, Fujii Masao wrote:
I think that the advantage of registering standbys is that we can
specify which WAL files the master has to keep for the upcoming
standby. IMO, it's usually called together with pg_start_backup
as follows:
SELECT register_standby('foo',
=?iso-8859-1?Q?PostgreSQL_-_Hans-J=FCrgen_Sch=F6nig?= postg...@cybertec.at
writes:
On Sep 1, 2010, at 4:10 PM, Tom Lane wrote:
This is really premature, and anything you do along those lines now will
probably never get committed.
well, why non-overlapping? the idea is to make append smart
There are many comments in the code which use serializable
transaction to mean transaction snapshot based transaction. This
doesn't matter much as long as REPEATABLE READ and SERIALIZABLE
transaction isolation levels behave identically, but will be
confusing and inaccurate when there is any
On Wed, Sep 1, 2010 at 3:49 PM, Cristian Bittel cbit...@gmail.com wrote:
Maybe the issue, for the momtent, could be avoided modifying the shared heap
for sessions on Windows. But I don't really have idea how much to increase
or decrease the values. Try and error? But, inside the opened Windows
On Sep 1, 2010, at 12:30 AM, Pavel Stehule wrote:
Docs is wrong :) I like current implementation. You can remove a NULLs
from aggregation very simply, but different direction isn't possible
Would appreciate the recipe for removing the NULLs.
Best,
David
--
Sent via pgsql-hackers mailing
Maybe the issue, for the momtent, could be avoided modifying the shared heap
for sessions on Windows. But I don't really have idea how much to increase
or decrease the values. Try and error? But, inside the opened Windows
sessions nothing alerts of a heap exaust so could be unpredictable how much
hello tom,
yeah, we have followed quite a lot of discussion as well ...
and yes, no patches.
as far as this problem is concerned: we are working on a patch and did some
prototyping inside the planner already (attached).
the code we have is pretty limited atm (such as checking for a sort clause
Hey -hackers,
In doing a schema upgrade, we noticed the following behavior, which certainly
seems like a bug. Steps to reproduce:
CREATE USER a;
CREATE USER b;
CREATE TABLE t1 (id serial primary key);
CREATE TABLE t2 (id int references t1(id));
ALTER TABLE t1 OWNER TO a;
David Christensen da...@endpoint.com writes:
In doing a schema upgrade, we noticed the following behavior, which certainly
seems like a bug. Steps to reproduce:
...
The bug in this case is that b has full permissions on all of the
underlying tables, but runs into issues when trying to
On Sep 1, 2010, at 1:06 AM, Thom Brown wrote:
I think it might be both. array_agg doesn't return NULL, it returns
an array which contains NULL.
The second I wrote that, I realised it was b*ll%$ks, as I was still in
the process of waking up.
I know that feeling.
/me sips his coffee
Best,
On Wed, Sep 1, 2010 at 6:23 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm not sure what we should aim for in the first phase. But if you want as
little code as possible yet have something useful, I think 'replay' mode
with no standby registration is the way to go.
IMHO,
On Sep 1, 2010, at 12:30 AM, Pavel Stehule wrote:
So are the docs right, or is array_agg() right?
Docs is wrong :) I like current implementation. You can remove a NULLs
from aggregation very simply, but different direction isn't possible
Patch:
diff --git a/doc/src/sgml/syntax.sgml
David E. Wheeler da...@kineticode.com writes:
*** 1543,1549
The first form of aggregate expression invokes the aggregate
across all input rows for which the given expression(s) yield
non-null values. (Actually, it is up to the aggregate function
! whether to ignore
On Sep 1, 2010, at 10:12 AM, Tom Lane wrote:
I think when that text was written, it was meant to imply all the
aggregates defined in SQL92. There seems to be a lot of confusion
in this thread about whether standard means defined by SQL spec
or built-in in Postgres. Should we try to refine
David E. Wheeler da...@kineticode.com writes:
On Sep 1, 2010, at 10:12 AM, Tom Lane wrote:
Even more to the point, should we deliberately make this vaguer so that
we aren't finding ourselves with obsolete text again and again? You can
bet that people adding new aggregates in the future aren't
On Wed, Sep 01, 2010 at 08:16:41AM -0700, David Wheeler wrote:
On Sep 1, 2010, at 12:30 AM, Pavel Stehule wrote:
Docs is wrong :) I like current implementation. You can remove a
NULLs from aggregation very simply, but different direction isn't
possible
Would appreciate the recipe for
On 1 September 2010 18:47, David Fetter da...@fetter.org wrote:
On Wed, Sep 01, 2010 at 08:16:41AM -0700, David Wheeler wrote:
On Sep 1, 2010, at 12:30 AM, Pavel Stehule wrote:
Docs is wrong :) I like current implementation. You can remove a
NULLs from aggregation very simply, but
On Sep 1, 2010, at 10:52 AM, Thom Brown wrote:
ould appreciate the recipe for removing the NULLs.
WHERE clause :P
There may be cases where that's undesirable, such as there being more
than one aggregate in the SELECT list, or the column being grouped on
needing to return rows regardless
On Wed, 2010-09-01 at 08:33 +0300, Heikki Linnakangas wrote:
On 01/09/10 04:02, Robert Haas wrote:
See the thread on interruptible sleeps. The problem
right now is that there are some polling loops that act to throttle
the maximum rate at which a node doing sync rep can make forward
On Sep 1, 2010, at 10:30 AM, Tom Lane wrote:
Hm, actually the whole para needs work. It was designed at a time when
DISTINCT automatically discarded nulls, which isn't true anymore, and
that fact was patched-in in a very awkward way too. Perhaps something
like
The first form of
2010/9/1 Thom Brown t...@linux.com:
On 1 September 2010 18:47, David Fetter da...@fetter.org wrote:
On Wed, Sep 01, 2010 at 08:16:41AM -0700, David Wheeler wrote:
On Sep 1, 2010, at 12:30 AM, Pavel Stehule wrote:
Docs is wrong :) I like current implementation. You can remove a
NULLs from
On Sep 1, 2010, at 11:09 AM, Pavel Stehule wrote:
Then you can eliminate NULLs with simple function
CREATE OR REPLACE FUNCTION remove_null(anyarray)
RETURNS anyarray AS $$
SELECT ARRAY(SELECT x FROM unnest($1) g(x) WHERE x IS NOT NULL)
$$ LANGUAGE sql;
Kind of defeats the purpose of the
David E. Wheeler da...@kineticode.com writes:
On Sep 1, 2010, at 10:30 AM, Tom Lane wrote:
Most aggregate functions ignore null inputs, so that rows in which
one or more of the expression(s) yield null are discarded. (This
can be assumed to be true, unless otherwise specified, for all
David E. Wheeler da...@kineticode.com writes:
On Sep 1, 2010, at 11:09 AM, Pavel Stehule wrote:
Then you can eliminate NULLs with simple function
Kind of defeats the purpose of the efficiency of the aggregate.
Well, you can build your own version of array_agg with the same
implementation,
2010/9/1 Tom Lane t...@sss.pgh.pa.us:
David E. Wheeler da...@kineticode.com writes:
On Sep 1, 2010, at 11:09 AM, Pavel Stehule wrote:
Then you can eliminate NULLs with simple function
Kind of defeats the purpose of the efficiency of the aggregate.
Well, you can build your own version of
Compiling with RELCACHE_FORCE_RELEASE doesn't pass make check on my
machine.
Is it supposed to pass?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/1 Tom Lane t...@sss.pgh.pa.us:
Well, you can build your own version of array_agg with the same
implementation, except you mark the transition function as strict ...
I am checking this now, and it is not possible - it needs a some
initial
2010/9/1 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/1 Tom Lane t...@sss.pgh.pa.us:
Well, you can build your own version of array_agg with the same
implementation, except you mark the transition function as strict ...
I am checking this now, and it is
Jeff Davis pg...@j-davis.com writes:
Compiling with RELCACHE_FORCE_RELEASE doesn't pass make check on my
machine.
What happens exactly?
Is it supposed to pass?
It shouldn't crash, but I'm not certain whether you'd see any
visible diffs in the tests.
regards, tom lane
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Greg Sabino Mullane wrote:
Specifically, LANGUAGE changes the headers of pg_controldata
(but not the actual output, LC_ALL does that). Thanks for the
nudge, I'll get to rewriting some code.
pg_upgrade does this in controldata.c
On Wed, 2010-09-01 at 13:23 +0300, Heikki Linnakangas wrote:
On 01/09/10 10:53, Fujii Masao wrote:
Before discussing about that, we should determine whether registering
standbys in master is really required. It affects configuration a lot.
Heikki thinks that it's required, but I'm still
Excerpts from Bruce Momjian's message of mié sep 01 16:35:18 -0400 2010:
I have implemented your suggestion of setting LANG, LANGUAGE, and
LC_MESSAGES based on code in pg_regress.c; that is the only place I see
where we force English, and it certainly has received more testing.
I think a
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Bruce Momjian's message of mié sep 01 16:35:18 -0400 2010:
I have implemented your suggestion of setting LANG, LANGUAGE, and
LC_MESSAGES based on code in pg_regress.c; that is the only place I see
where we force English, and it
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Bruce Momjian's message of mi?? sep 01 16:35:18 -0400 2010:
I have implemented your suggestion of setting LANG, LANGUAGE, and
LC_MESSAGES based on code in pg_regress.c; that is the only place I see
where we
Jeff Davis pg...@j-davis.com writes:
On Wed, 2010-09-01 at 15:31 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
Compiling with RELCACHE_FORCE_RELEASE doesn't pass make check on my
machine.
What happens exactly?
I have attached regression.diffs after a make check. The diffs
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
However, that's something for 9.1 and beyond. Bruce's immediate problem
is what to do in pg_upgrade in 9.0, and there I concur that he should
duplicate what pg_regress is doing.
OK, here is a patch that sets all the variables that
On Sep 1, 2010, at 10:21 AM, Greg Stark gsst...@mit.edu wrote:
For what it's worth I disagree with Tom. I think this is a situation
where we need *both* types of solution. Ideally we will be able to use
a plain Append node for cases where we know the relative ordering of
the data in different
On Sep 1, 2010, at 11:02 AM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
The patch to implement true serializable transactions using SSI
renames/rewords these things to avoid confusion. However, there are
seven files which are changed only for this reason, and another
where there is
I wrote:
Jeff Davis pg...@j-davis.com writes:
I have attached regression.diffs after a make check. The diffs don't
look trivial, and actually look quite strange to me.
Hmm, sorta looks like that breaks something related to checking for
composite types. That would be a bug. Will look.
So
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
However, that's something for 9.1 and beyond. Bruce's immediate problem
is what to do in pg_upgrade in 9.0, and there I concur that he should
duplicate what pg_regress is doing.
OK, here is a patch that sets all
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I certainly hope that pg_regress isn't freeing the strings it passes
to putenv() ...
pg_regress does not restore these settings (it says with C/English) so
the code is different.
That's not what I'm on about. You're trashing strings
Jeff Davis pg...@j-davis.com writes:
I have attached regression.diffs after a make check. The diffs don't
look trivial, and actually look quite strange to me.
BTW, if I dike out the flush_rowtype_cache call at relcache.c:1929,
the regression tests do pass for me, so it seems there is only one
This patch allows external security providers to check privileges
to create a new relation and to inform the security labels to be
assigned on the new one.
This hook is put on DefineRelation() and OpenIntoRel(), but isn't
put on Boot_CreateStmt, create_toast_table() and make_new_heap(),
although
I wrote:
Probably the best fix would be to make typcache flushing fully
independent of the relcache, but that would mean making sure that all
ALTER TABLE variants that affect the rowtype will issue an explicit
typcache flush. That seems a bit too invasive to be back-patchable.
I'm not
2010/9/1 KaiGai Kohei kai...@ak.jp.nec.com:
Right now, it stands on a strict assumption that considers operators
implemented with built-in functions are safe; it does not have no
possibility to leak supplied arguments anywhere.
Please note that this patch does not case about a case when
a
2010/8/28 Alexander Korotkov aekorot...@gmail.com:
Now test for levenshtein_less_equal performance.
Nice results. I'll try to find time to look at this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list
2010/8/25 Boszormenyi Zoltan z...@cybertec.at:
PostgreSQL allows in plain SQL to declare a cursor
e.g. in all lower case and fetch from is in all upper case.
We need to allow this from ECPG, too, but strictly when
the cursor name is not in a variable. Otherwise this code
below doesn't notice
On Mon, Aug 30, 2010 at 5:30 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-08-31 12:07 AM +0300, I wrote:
I looked at fixing this..
The previous patch had a bug in fmgr_sql() our regression tests didn't
catch. Fixed version attached.
It would probably be a good idea to
On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander mag...@hagander.net wrote:
That definitely didn't fix it, although I'm not quite sure why. Can
you throw the modified CVS you ran this off of up somewhere I can
rsync it?
no rsync server on that box, but I put up a tarball for you at
(2010/09/02 11:57), Robert Haas wrote:
2010/9/1 KaiGai Koheikai...@ak.jp.nec.com:
Right now, it stands on a strict assumption that considers operators
implemented with built-in functions are safe; it does not have no
possibility to leak supplied arguments anywhere.
Please note that this
2010/9/1 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/09/02 11:57), Robert Haas wrote:
2010/9/1 KaiGai Koheikai...@ak.jp.nec.com:
Right now, it stands on a strict assumption that considers operators
implemented with built-in functions are safe; it does not have no
possibility to leak supplied
On Wed, Sep 1, 2010 at 4:11 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The obvious next question is how to wait for multiple sockets and a latch at
the same time? Perhaps we should have a select()-like interface where you
can pass multiple file descriptors. Then again,
(2010/09/02 12:38), Robert Haas wrote:
2010/9/1 KaiGai Koheikai...@ak.jp.nec.com:
(2010/09/02 11:57), Robert Haas wrote:
2010/9/1 KaiGai Koheikai...@ak.jp.nec.com:
Right now, it stands on a strict assumption that considers operators
implemented with built-in functions are safe; it does not
On Wed, 2010-09-01 at 20:57 -0400, Tom Lane wrote:
I wrote:
Probably the best fix would be to make typcache flushing fully
independent of the relcache, but that would mean making sure that all
ALTER TABLE variants that affect the rowtype will issue an explicit
typcache flush. That seems
70 matches
Mail list logo
