On Thu, 2011-09-22 at 02:31 +0200, Florian Pflug wrote:
My personal favourite would be '0', since it resembles the symbol used
for empty sets in mathematics, and we already decided to use mathematical
notation for ranges.
If we're concerned that most of our users won't get that, then 'empty'
On 22.09.2011 07:51, Tom Lane wrote:
Here's a revised version of the patch that behaves in a way that seems
reasonable to me, in particular it suppresses zero filter-count rows in
text mode. I've not done anything yet about the documentation.
I haven't been following this closely, so sorry if
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I haven't been following this closely, so sorry if this has already been
discussed, but:
I find it a bit strange to print the number of lines filtered out. I
think that's the only place where we would print a negative like that,
On 06.09.2011 20:34, Oleg Bartunov wrote:
Here is the latest spgist patch, which has all planned features as well as
all overhead, introduced by concurrency and recovery, so performance
measurement should be realistic now.
I'm ignoring the text suffix-tree part of this for now, because of the
Very sorry for late reply.
You are right, _xpg_ socket functionality is not available in older systems, it
is available in hp-ux 11.23 version through patch HCO_35744 . HPUX 10.20 is
very old machine (1996). I am using latest HPUX B.11.31 machine, I don't have
access to older systems.
On Thu, Sep 22, 2011 at 2:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Regarding the quadtree, have you compared the performance of that with
Alexander's improved split algorithm? I ran some tests using the test
harness I still had lying around from the fast GiST index
! /*
!* Calculate delta between penalties of join common entries to
!* different groups.
!*/
! for (i = 0; i commonEntriesCount; i++)
{
! double lower,
!
Thank you for your understanding on that point.
At Wed, 21 Sep 2011 20:35:02 -0400, Robert Haas robertmh...@gmail.com wrote
...while Kyotaro Horiguchi clearly feels otherwise, citing the
statistic that about 100 out of 7000 Japanese characters fail to work
properly:
On Thu, Sep 22, 2011 at 3:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
! /*
!* Calculate delta between penalties of join common
entries to
!* different groups.
!*/
! for (i = 0; i
On Wed, Sep 21, 2011 at 5:34 PM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Sep 21, 2011 at 08:23, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 21, 2011 at 2:13 PM, Magnus Hagander mag...@hagander.net wrote:
Presumably pg_start_backup() will check this. And we'll somehow track
On Thu, Sep 22, 2011 at 12:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm a bit perplexed as to why we can't find a non-stochastic way of doing
this.
[ collations suck ]
Ugh.
Now, having said that, I'm starting to wonder again why it's worth our
On Thu, Sep 22, 2011 at 1:49 PM, Robert Haas robertmh...@gmail.com wrote:
My thought was that it would avoid the need to do any character
incrementing at all. You could just start scanning forward as if the
operator were = and then stop when you hit the first string that
doesn't have the same
On Sun, Sep 18, 2011 at 5:39 AM, Kerem Kat kerem...@gmail.com wrote:
I am new to postgresql code, I would like to start implementing easyish TODO
items. I have read most of the development guidelines, faqs, articles by
Greg Smith (Hacking Postgres with UDFs, Adding WHEN to triggers).
The item
On Wed, Sep 21, 2011 at 11:50 AM, Fujii Masao masao.fu...@gmail.com wrote:
2011/9/13 Jun Ishiduka ishizuka@po.ntts.co.jp:
Update patch.
Changes:
* set 'on' full_page_writes by user (in document)
* read FROM: XX in backup_label (in xlog.c)
* check status when pg_stop_backup is
On Thu, Sep 22, 2011 at 8:59 AM, Greg Stark st...@mit.edu wrote:
On Thu, Sep 22, 2011 at 1:49 PM, Robert Haas robertmh...@gmail.com wrote:
My thought was that it would avoid the need to do any character
incrementing at all. You could just start scanning forward as if the
operator were = and
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 22, 2011 at 8:59 AM, Greg Stark st...@mit.edu wrote:
But the whole problem is that not all the strings with the initial
substring are in a contiguous block.
If that were true for the sorts of indexes we're using for LIKE
queries, the
On Wed, Sep 21, 2011 at 5:07 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
That's the sort of thing where it would be helpful to provide one or
two URLs for cogent explanations of this. Even if it takes repeated
readings and meditations on the explanations for it to sink in, this
is
Hello
Before doing the complete review, I hit a regression with 9.1 createrole.
the command ''createuser -e -s foo produce :
CREATE ROLE foo SUPERUSER CREATEDB CREATEROLE INHERIT LOGIN NOREPLICATION;
before it was:
CREATE ROLE foo SUPERUSER CREATEDB CREATEROLE INHERIT LOGIN;
The
I delved into the code without waiting for comments from the list just to
learn something about postgresql internals. And I have finished the
CORRESPONDING, now CORRESPONDING BY is being tested. I will also write
documentation and regression tests.
Yes Robert, you are correct. Having used SQL
2.2. pg_start_backup(Obackup_under_loadš) on the master (this will take a
while as master is loaded up);
No. if you use pg_start_backup('foo', true) it will be fast. Check the
manual.
If the server is sufficiently heavily loaded that a checkpoint takes a
nontrivial amount of time, the OP
On Thu, Sep 22, 2011 at 2:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The essential problem here is when can you stop scanning,
given a pattern with this prefix?, and btree doesn't know any more
about that than make_greater_string does; it would in fact have to use
make_greater_string or
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 22, 2011 at 12:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Now, having said that, I'm starting to wonder again why it's worth our
trouble to fool with encoding-specific incrementers. The exactness of
the estimates seems unlikely to be
Greg Stark st...@mit.edu writes:
On Thu, Sep 22, 2011 at 2:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The essential problem here is when can you stop scanning,
given a pattern with this prefix?, and btree doesn't know any more
about that than make_greater_string does; it would in fact have to
On 14 September 2011 21:29, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas robertmh...@gmail.com wrote:
I've been thinking about this too and actually went so far as to do
some research and put together something that I hope covers most of
the interesting
While testing I noticed that ordering is incorrect in my implementation. At
first I thought that removing mismatched entries from ltargetlist and
rtargetlist would be enough, it didn't seem enough so I added rtargetlist
sorting.
SELECT 1 a, 2 b, 3 c UNION CORRESPONDING 4 b, 5 a, 6 c;
returns
On Thu, Sep 22, 2011 at 10:53 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
As I've already pointed out, the comment Won't work on Visual Studio
2003 is not accurate:
http://msdn.microsoft.com/en-us/library/f20w0x5e(v=vs.71).aspx
Besides, if it's not supported, why bother mentioning it?
On 22 September 2011 16:18, Robert Haas robertmh...@gmail.com wrote:
On Thu, Sep 22, 2011 at 10:53 AM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
As I've already pointed out, the comment Won't work on Visual Studio
2003 is not accurate:
On Thu, Sep 22, 2011 at 10:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Anyway, I won't stand in the way of the patch as long as it's modified
to limit the number of values considered for any one character position
to something reasonably small.
One thing I was thinking about is that it would be
On Thu, Sep 22, 2011 at 11:25 AM, Thom Brown t...@linux.com wrote:
s/visca-versa/vice-versa/
s/laods/loads/
Fixed. v4 attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
barrier-v4.patch
Description: Binary data
--
Sent via pgsql-hackers
Before 9.x, how do unaccent full text searches ?
i
2011/9/21 Tom Lane t...@sss.pgh.pa.us
Euler Taveira de Oliveira eu...@timbira.com writes:
On 21-09-2011 13:28, Daniel Vázquez wrote:
unaccent is compatible with postgresql 8.4 (but not is in their
contrib
version distribution)
No, it
On Thu, Sep 22, 2011 at 14:13, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 21, 2011 at 5:34 PM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Sep 21, 2011 at 08:23, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 21, 2011 at 2:13 PM, Magnus Hagander mag...@hagander.net
Excerpts from Robert Haas's message of jue sep 22 12:18:47 -0300 2011:
I've also added a lengthy README file to the patch that attempts to
explain how barriers should be used in PostgreSQL coding.
Very enlightening, thanks. Note a typo laods.
--
Álvaro Herrera alvhe...@commandprompt.com
Robert Haas robertmh...@gmail.com writes:
One thing I was thinking about is that it would be useful to have some
metric for judging how well any given algorithm that we might pick
here actually works.
Well, the metric that we were indirectly using earlier was the
number of characters in a
On 22-09-2011 12:39, Daniel Vázquez wrote:
Before 9.x, how do unaccent full text searches ?
Perform pre-processing (normalization) of the string *before* inserting and
*before* searching.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria,
2011/9/22 Daniel Vázquez daniel2d2...@gmail.com:
Before 9.x, how do unaccent full text searches ?
It seems that Oleg has published something on his web site that
supposedly works with 8.4:
http://www.sai.msu.su/~megera/wiki/unaccent
But I'm not really sure how it works, or even where the
On 22-09-2011 11:24, Linas Virbalas wrote:
In order to check more cases, I have changed the procedure to force an
immediate checkpoint, i.e. pg_start_backup('backup_under_load', true). With
the same load generator running, pg_start_backup returned almost
instantaneously compared to how long it
On Thu, Sep 22, 2011 at 11:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, the metric that we were indirectly using earlier was the
number of characters in a given locale for which the algorithm
fails to find a greater one (excluding whichever character is last,
I guess, or you could just
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 22, 2011 at 11:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, the metric that we were indirectly using earlier was the
number of characters in a given locale for which the algorithm
fails to find a greater one (excluding whichever
On Thu, Sep 22, 2011 at 10:55 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
Before doing the complete review, I hit a regression with 9.1 createrole.
Thanks!
the command ''createuser -e -s foo produce :
CREATE ROLE foo SUPERUSER CREATEDB CREATEROLE INHERIT LOGIN
On Thu, Sep 22, 2011 at 02:41:12AM -0400, Tom Lane wrote:
Yeah, I thought seriously about that too. The problem with it is that
you end up having to print that line all the time, whether or not it
adds any knowledge. The filter removed N rows approach has the saving
grace that you can leave
1. citext_eq(citext,citext)
2. citext_eq(text,citext)
3. citext_eq(citext,text)
Then the question is: does it find only #2 via polymorphic lookup, or does it
think that either #1 or #2 could work (because text supports an implicit cast
to citext, IIRC). If it's more than one it's an
On Sep 22, 2011, at 9:53 AM, Josh Berkus wrote:
Then the question is: does it find only #2 via polymorphic lookup, or does
it think that either #1 or #2 could work (because text supports an implicit
cast to citext, IIRC). If it's more than one it's an error. Not sure if the
same issue
Well, I just ran through the 7 potential combinations, and didn't get
any errors. Hard to tell which function is being used, of course.
That's what tests are for.
So, tell me how to write a test to check which function is being used.
--
Josh Berkus
PostgreSQL Experts Inc.
On Sep 22, 2011, at 10:11 AM, Josh Berkus wrote:
That's what tests are for.
So, tell me how to write a test to check which function is being used.
Just write some comparisons like upthread, and see if the output is f or t. Put
them into sql/citext.sql.
Best,
David
--
Sent via
2011/9/22 Euler Taveira de Oliveira eu...@timbira.com:
On 22-09-2011 11:24, Linas Virbalas wrote:
In order to check more cases, I have changed the procedure to force an
immediate checkpoint, i.e. pg_start_backup('backup_under_load', true).
With
the same load generator running,
Robert Haas robertmh...@gmail.com wrote:
I've also added a lengthy README file to the patch that attempts
to explain how barriers should be used in PostgreSQL coding. It's
certainly not a comprehensive treatment of the topic, but
hopefully it's enough to get people oriented. I've attempted
On 9/22/11 10:26 AM, David E. Wheeler wrote:
On Sep 22, 2011, at 10:11 AM, Josh Berkus wrote:
That's what tests are for.
So, tell me how to write a test to check which function is being used.
Just write some comparisons like upthread, and see if the output is f or t.
Put them into
On Sep 22, 2011, at 10:50 AM, Josh Berkus wrote:
Just write some comparisons like upthread, and see if the output is f or t.
Put them into sql/citext.sql.
Oh, ok. I thought you meant checking the actual function call.
Tests go in the main SQL file? Shouldn't they have their own file?
Excerpts from David E. Wheeler's message of jue sep 22 14:51:59 -0300 2011:
On Sep 22, 2011, at 10:50 AM, Josh Berkus wrote:
Just write some comparisons like upthread, and see if the output is f or
t. Put them into sql/citext.sql.
Oh, ok. I thought you meant checking the actual
On Sep 22, 2011, at 11:07 AM, Alvaro Herrera wrote:
That is the test file. The main SQL file is citext--1.0.sql. You'll actually
need to bump the version number to 1.1, rename that file to citext--1.1.sql,
and also add them to a citext--1.0--1.1.sql. There probably also needs to be
a
David E. Wheeler da...@kineticode.com wrote:
On Sep 22, 2011, at 11:07 AM, Alvaro Herrera wrote:
Hmm, if there's a citext--unpackaged--1.0.sql and also
citext--1.0--1.1.sql, is it really necessary to have
citext--unpackaged--1.1.sql? Shouldn't the upgrade facility be
able to just run both
On Sep 22, 2011, at 11:14 AM, Kevin Grittner wrote:
No, because if 1.1 was installed on 8.4, you'd need the commands
to move all its functions into the extension, not re-create them.
Shouldn't a version installed on 8.4 be installed as unpackaged?
Doesn't citext--unpackaged--1.0.sql contain
On Thu, Sep 22, 2011 at 2:16 PM, David E. Wheeler da...@kineticode.com wrote:
On Sep 22, 2011, at 11:14 AM, Kevin Grittner wrote:
No, because if 1.1 was installed on 8.4, you'd need the commands
to move all its functions into the extension, not re-create them.
Shouldn't a version installed
On Sep 22, 2011, at 11:23 AM, Robert Haas wrote:
I believe the point David is trying to make is that someone might take
an 9.2 version of a contrib module and manually install it on an 8.4
server by executing the install script, perhaps with some amount of
hackery.
Right.
But I don't think
But I don't think we're required to support that case. If the user
does a non-standard install, it's their job to deal with the fallout.
Well, I'll write the script anyway, since *I* need it. I'm installing
this on a 9.0 database which will be later upgraded to 9.1.
However, before I write
On Thu, Sep 22, 2011 at 2:36 PM, Josh Berkus j...@agliodbs.com wrote:
But I don't think we're required to support that case. If the user
does a non-standard install, it's their job to deal with the fallout.
Well, I'll write the script anyway, since *I* need it. I'm installing
this on a 9.0
On Thu, Sep 22, 2011 at 3:31 PM, Alexander Korotkov aekorot...@gmail.comwrote:
On Thu, Sep 22, 2011 at 3:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
'lower' and 'upper' are not used for anything in the above. Is that just
dead code that can be removed, or is there
note: some basic test shows about 15% speedup
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2011-09-22 at 11:31 -0400, Robert Haas wrote:
On Thu, Sep 22, 2011 at 11:25 AM, Thom Brown t...@linux.com wrote:
s/visca-versa/vice-versa/
s/laods/loads/
Fixed. v4 attached.
Can you please explain the more subtly part below?
+A common pattern where this actually does result in
On Thu, Sep 22, 2011 at 5:45 PM, Jeff Davis pg...@j-davis.com wrote:
+This code turns out to be unsafe, because the writer might increment
+q-num_items before it finishes storing the new item into the
appropriate slot.
+More subtly, the reader might prefetch the contents of the q-items
array
On Thu, Sep 22, 2011 at 5:10 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
note: some basic test shows about 15% speedup
Eh that's good, but I think you need to fix the fact that it crashes...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
On Thu, 2011-09-22 at 19:12 -0400, Robert Haas wrote:
But since you asked... as I
understand it, unless you're running on Alpha, you actually don't need
a barrier here at all, because all currently-used CPUs other than
alpha respect data dependencies, which means that if q-num_items is
used
On Thu, Sep 22, 2011 at 7:46 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2011-09-22 at 19:12 -0400, Robert Haas wrote:
But since you asked... as I
understand it, unless you're running on Alpha, you actually don't need
a barrier here at all, because all currently-used CPUs other than
alpha
Hello
2011/9/23 Robert Haas robertmh...@gmail.com:
On Thu, Sep 22, 2011 at 5:10 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
note: some basic test shows about 15% speedup
Eh that's good, but I think you need to fix the fact that it crashes...
I fixed crash that described Tom. Do you
Kerem Kat kerem...@gmail.com writes:
While testing I noticed that ordering is incorrect in my implementation. At
first I thought that removing mismatched entries from ltargetlist and
rtargetlist would be enough, it didn't seem enough so I added rtargetlist
sorting.
I don't think you can get
... moving to hackers ...
On Mon, Nov 23, 2009 at 7:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 20, 2009 at 6:56 PM, Alvaro Herrera alvhe...@postgresql.org
wrote:
I have two suggestions to fix this:
1. avoid displaying any value at all as
66 matches
Mail list logo
