... moving to hackers ...
On Mon, Nov 23, 2009 at 7:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Nov 20, 2009 at 6:56 PM, Alvaro Herrera
>> wrote:
>>> I have two suggestions to fix this:
>>>
>>> 1. avoid displaying any value at all as if it were the true default (this
>>> would perh
Kerem Kat 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 away with changi
Hello
2011/9/23 Robert Haas :
> On Thu, Sep 22, 2011 at 5:10 PM, Pavel Stehule
> 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 know about other?
Regards
Pavel
> --
On Thu, Sep 22, 2011 at 7:46 PM, Jeff Davis 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 "respect
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
>
On Thu, Sep 22, 2011 at 5:10 PM, Pavel Stehule 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
--
Sent via pgsql-hackers ma
On Thu, Sep 22, 2011 at 5:45 PM, Jeff Davis 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
> +before r
On Thu, 2011-09-22 at 11:31 -0400, Robert Haas wrote:
> On Thu, Sep 22, 2011 at 11:25 AM, Thom Brown 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 a bu
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, Sep 22, 2011 at 3:31 PM, Alexander Korotkov wrote:
> 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 something mi
On Thu, Sep 22, 2011 at 2:36 PM, Josh Berkus 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 database wh
> 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 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 t
On Thu, Sep 22, 2011 at 2:16 PM, David E. Wheeler 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 8.4 be
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
"David E. Wheeler" 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 scripts?
>
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
>>
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
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
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
Robert Haas 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 to
> tailor it a
2011/9/22 Euler Taveira de Oliveira :
> 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 retur
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 pgsql-
>> 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.
http://pge
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
> 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
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 l
On Thu, Sep 22, 2011 at 10:55 PM, Cédric Villemain
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 NOREPLICATION;
>
> before it was:
> CREATE
Robert Haas writes:
> On Thu, Sep 22, 2011 at 11:46 AM, Tom Lane 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 c
On Thu, Sep 22, 2011 at 11:46 AM, Tom Lane 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 recognize there's
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 to
2011/9/22 Daniel Vázquez :
> 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 source code
is. I would su
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, D
Robert Haas 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 given locale for which
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
The PostgreSQL Company -
On Thu, Sep 22, 2011 at 14:13, Fujii Masao wrote:
> On Wed, Sep 21, 2011 at 5:34 PM, Magnus Hagander wrote:
>> On Wed, Sep 21, 2011 at 08:23, Fujii Masao wrote:
>>> On Wed, Sep 21, 2011 at 2:13 PM, Magnus Hagander
>>> wrote:
Presumably pg_start_backup() will check this. And we'll somehow
Before 9.x, how do unaccent full text searches ?
i
2011/9/21 Tom Lane
> Euler Taveira de Oliveira 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 is not. AFAICS it is
On Thu, Sep 22, 2011 at 11:25 AM, Thom Brown 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 mailing list (
On Thu, Sep 22, 2011 at 10:36 AM, Tom Lane 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 useful to have s
On 22 September 2011 16:18, Robert Haas wrote:
> On Thu, Sep 22, 2011 at 10:53 AM, Peter Geoghegan
> 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
On Thu, Sep 22, 2011 at 10:53 AM, Peter Geoghegan 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?
I mentioned it
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 incor
On 14 September 2011 21:29, Robert Haas wrote:
> On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas 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 cases. The attached patch is pretty
Greg Stark writes:
> On Thu, Sep 22, 2011 at 2:51 PM, Tom Lane 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_stri
Robert Haas writes:
> On Thu, Sep 22, 2011 at 12:24 AM, Tom Lane 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 improved very much by doing this.
> We
On Thu, Sep 22, 2011 at 2:51 PM, Tom Lane 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 something isomorphic
>>> 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 o
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 20n
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 REPLICATIO
On Wed, Sep 21, 2011 at 5:07 PM, Kevin Grittner
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 worth it. (For SSI I had
Robert Haas writes:
> On Thu, Sep 22, 2011 at 8:59 AM, Greg Stark 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 existing approach wouldn't work
On Thu, Sep 22, 2011 at 8:59 AM, Greg Stark wrote:
> On Thu, Sep 22, 2011 at 1:49 PM, Robert Haas 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 f
On Wed, Sep 21, 2011 at 11:50 AM, Fujii Masao wrote:
> 2011/9/13 Jun Ishiduka :
>>
>> 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 executed (in xlog.c)
>
> Thanks for u
On Sun, Sep 18, 2011 at 5:39 AM, Kerem Kat 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 I would like to
On Thu, Sep 22, 2011 at 1:49 PM, Robert Haas 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 initial substrin
On Thu, Sep 22, 2011 at 12:24 AM, Tom Lane wrote:
> Robert Haas 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
> trouble to fool with encoding-sp
On Wed, Sep 21, 2011 at 5:34 PM, Magnus Hagander wrote:
> On Wed, Sep 21, 2011 at 08:23, Fujii Masao wrote:
>> On Wed, Sep 21, 2011 at 2:13 PM, Magnus Hagander wrote:
>>> Presumably pg_start_backup() will check this. And we'll somehow track
>>> this before pg_stop_backup() as well? (for such evi
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 =
Thank you for your understanding on that point.
At Wed, 21 Sep 2011 20:35:02 -0400, Robert Haas wrote
> ...while Kyotaro Horiguchi clearly feels otherwise, citing the
> statistic that about 100 out of 7000 Japanese characters fail to work
> properly:
>
> http://archives.postgresql.org/pgsql-bugs
! /*
!* Calculate delta between penalties of join "common entries" to
!* different groups.
!*/
! for (i = 0; i < commonEntriesCount; i++)
{
! double lower,
!
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 i
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. -D_XOPEN_
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
63 matches
Mail list logo
