2013-01-05 05:58 keltezéssel, Amit kapila írta:
On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote:
Hi,
I am reviewing your patch.
Thank you very much.
Since you are using a constant string, it would be a little faster
to use "sizeof(string)-1" as it can be computed at compile-time
On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote:
> Hi,
> I am reviewing your patch.
Thank you very much.
> Since you are using a constant string, it would be a little faster
> to use "sizeof(string)-1" as it can be computed at compile-time
> and not run the strlen() all the time th
On 4 January 2013 22:42, Tom Lane wrote:
> Invent a "one-shot" variant of CachedPlans for better performance.
...
> Back-patch to 9.2, since this was a performance regression compared to 9.1.
> (In 9.2, place the added struct fields so as to avoid changing the offsets
> of existing fields.)
>
> H
> Well, of course, people with that type of problem should probably
> rethink their use of dynamic SQL when they move to 9.2 anyway, because
> that's the case where the new plancache code could actually help them
> if they'd only let it.
Oh, no question. But it'll take time for users with 1000's
On 4 January 2013 17:10, Robert Haas wrote:
> I don't really agree with this. To be honest, my biggest concern
> about this patch is that it will make it take longer to report an
> error. At least in the cases where these additional fields are
> included, it will take CPU time to populate those
On 4 January 2013 18:07, Tom Lane wrote:
> Exactly. To my mind, the *entire* point of this patch is to remove the
> need for people to try to dig information out of potentially-localized
> message strings. It's not clear to me that we have to strain to provide
> information that isn't in the cur
On 01/04/2013 01:17 PM, Tom Lane wrote:
Well, of course, people with that type of problem should probably
rethink their use of dynamic SQL when they move to 9.2 anyway, because
that's the case where the new plancache code could actually help them
if they'd only let it.
Not to further the argu
Robert Haas writes:
> Mostly that it seems like a hack, and I suspect we may come up with a
> better way to do this in the future.
Do you have the specs of such better way? Would it be a problem to have
both pg_retainxlog and the new way?
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL
Alvaro Herrera writes:
> I gave this patch a look. I'm not done with it; I mostly gave the
> utility.c changes some love so that the end result is not as cluttered.
Thanks Álvaro!
> I did this by creating a couple of macros that call the Start() thing,
> then set the OID, then call the End() th
Josh Berkus writes:
>> Next question is what people think about back-patching into 9.2 so as
>> to eliminate the performance regression vs 9.1.
> 8% is a pretty serious regression, for those of us with applications
> which do a lot of dynamic SQL. As a reminder, many people do dynamic
> SQL even
2013/1/4 Andrew Dunstan :
>
> On 01/04/2013 03:36 PM, Pavel Stehule wrote:
>>
>> Hello
>>
>>
>>
>> 2013/1/4 Andrew Dunstan :
>>>
>>> On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
On 01/02/2013 04:45 PM, Robert Haas wrote:
>
> On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan
>
Alvaro Herrera escribió:
> I gave this patch a look. I'm not done with it; I mostly gave the
> utility.c changes some love so that the end result is not as cluttered.
> I did this by creating a couple of macros that call the Start() thing,
> then set the OID, then call the End() thing. This made
Dimitri Fontaine escribió:
> Robert Haas writes:
> > OK, I committed this.
>
> Thanks. Please find attached a rebased patch, v6. I think it's looking
> more like what you would expect now:
I gave this patch a look. I'm not done with it; I mostly gave the
utility.c changes some love so that the
On 01/04/2013 03:36 PM, Pavel Stehule wrote:
Hello
2013/1/4 Andrew Dunstan :
On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan
wrote:
Here is a patch for the first part of the JSON API that was recent
Hello
2013/1/4 Andrew Dunstan :
>
> On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
>>
>>
>> On 01/02/2013 04:45 PM, Robert Haas wrote:
>>>
>>> On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan
>>> wrote:
Here is a patch for the first part of the JSON API that was recently
discussed.
On 01/04/2013 12:05 PM, Josh Berkus wrote:
Next question is what people think about back-patching into 9.2 so as
to eliminate the performance regression vs 9.1. I believe this would
be safe (although some care would have to be taken to put the added
boolean fields into places where they'd no
Samuel Vogel writes:
> I'm trying to print out the tuples in the b-tree nodes for analysis, but
> when iterate over more than the first entry of the tuples (scanKey++), I
> strangely get the error below on query execution:
> ERROR: relation "simpletest" does not exist
> LINE 1: SELECT * FROM si
On 04.01.2013 22:05, Josh Berkus wrote:
Next question is what people think about back-patching into 9.2 so as
to eliminate the performance regression vs 9.1. I believe this would
be safe (although some care would have to be taken to put the added
boolean fields into places where they'd not res
> Next question is what people think about back-patching into 9.2 so as
> to eliminate the performance regression vs 9.1. I believe this would
> be safe (although some care would have to be taken to put the added
> boolean fields into places where they'd not result in an ABI break).
> However it
2013/1/4 Tom Lane :
> "Dong Ye" writes:
>> I did three back-to-back runs using the same settings as in
>> http://archives.postgresql.org/pgsql-performance/2012-11/msg7.php
>> Except:
>> - use no prepared statement
>> - use 40 db connections
>> - build source from postgresql.git on the server b
"Dong Ye" writes:
> I did three back-to-back runs using the same settings as in
> http://archives.postgresql.org/pgsql-performance/2012-11/msg7.php
> Except:
> - use no prepared statement
> - use 40 db connections
> - build source from postgresql.git on the server box using: REL9_1_7,
> REL9_2
I did three back-to-back runs using the same settings as in
http://archives.postgresql.org/pgsql-performance/2012-11/msg7.php
Except:
- use no prepared statement
- use 40 db connections
- build source from postgresql.git on the server box using: REL9_1_7,
REL9_2_2, REL9_2_2 + this patch
NOTPM
On 1/3/13 12:30 PM, Robert Haas wrote:
> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander wrote:
>> Any particular reason? It goes pretty tightly together with
>> pg_receivexlog, which is why I'd prefer putting it alongside that one.
>> But if you have a good argument against it, I can change my m
"anara...@anarazel.de" writes:
> Robert Haas schrieb:
>> The people who are content to do that don't need this patch at all.
>> They can just apply a regexp to the message that comes back from the
>> server and then set constraint_name based on what pops out of the
>> regex. And then do just wha
On 1/3/13 3:26 PM, Robert Haas wrote:
> It's true, as we've often
> said here, that leveraging the OS facilities means that we get the
> benefit of improving OS facilities "for free" - but it also means that
> we never exceed what the OS facilities are able to provide.
And that should be the decid
2013-01-04 18:27 keltezéssel, Boszormenyi Zoltan írta:
One specific comment about the documentation part of the patch:
***
*** 86,92 SET [ SESSION | LOCAL ] TIME ZONE { class="PARAMETER">timezone
PL/pgSQL exception block. This behavior
has been changed because it
Hi,
I am reviewing your patch.
2012-12-10 13:58 keltezéssel, Amit kapila írta:
On Thu, 6 Dec 2012 10:12:31 +0530 Amit Kapila wrote:
On Tuesday, December 04, 2012 8:37 AM Amit Kapila wrote:
> On Monday, December 03, 2012 8:59 PM Tom Lane wrote:
> > Robert Haas writes:
> > > On Sat, Dec 1, 2012
Robert Haas schrieb:
>On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan
> wrote:
>> Ascertaining the identity of the object in question perfectly
>> unambiguously, so that you can safely do something like lookup a
>> comment on the object, seems like something way beyond what I'd
>> envisioned f
On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan wrote:
> Ascertaining the identity of the object in question perfectly
> unambiguously, so that you can safely do something like lookup a
> comment on the object, seems like something way beyond what I'd
> envisioned for this feature. Why should the
2013/1/4 Tom Lane :
> Pavel Stehule writes:
>> What is state of this issue?
>> http://archives.postgresql.org/pgsql-hackers/2011-09/msg00423.php
>
> AFAICS we never identified the cause. It was pretty clear that
> something was failing to clean up shared-memory lock data structures,
> but not wha
On Fri, Dec 28, 2012 at 1:21 PM, Peter Geoghegan wrote:
> Now, as to the question of whether we need to make sure that
> everything is always fully qualified - I respectfully disagree with
> Stephen, and maintain my position set out in the last round of
> feedback [1], which is that we don't need
On Mon, Dec 24, 2012 at 02:41:37AM +0100, Tomas Vondra wrote:
> + SMgrRelation *srels = palloc(sizeof(SMgrRelation));
> + int nrels = 0,
> + i = 0,
> + maxrels = 1;
maxrels=1 is not good -- too much palloc traff
Pavel Stehule writes:
> What is state of this issue?
> http://archives.postgresql.org/pgsql-hackers/2011-09/msg00423.php
AFAICS we never identified the cause. It was pretty clear that
something was failing to clean up shared-memory lock data structures,
but not what that something was. The last
On Mon, Dec 31, 2012 at 11:51 AM, Tomas Vondra wrote:
> I thought I followed the conding style - which guidelines have I broken?
+ /* If there are no non-local relations, then we're done. Release the
memory
+* and return. */
Multi-line comments should start with a line containing
On 4 January 2013 13:53, Amit Kapila wrote:
> On Friday, December 28, 2012 3:52 PM Simon Riggs wrote:
>> On 28 December 2012 08:07, Kyotaro HORIGUCHI
>> wrote:
>>
>> > Hello, I saw this patch and confirmed that
>> >
>> > - Coding style looks good.
>> > - Appliable onto HEAD.
>> > - Some mis-co
On Friday, December 28, 2012 3:52 PM Simon Riggs wrote:
> On 28 December 2012 08:07, Kyotaro HORIGUCHI
> wrote:
>
> > Hello, I saw this patch and confirmed that
> >
> > - Coding style looks good.
> > - Appliable onto HEAD.
> > - Some mis-codings are fixed.
>
> I've had a quick review of the p
On January 02, 2013 12:41 PM Hari Babu wrote:
>On January 01, 2013 10:19 PM Boszormenyi Zoltan wrote:
>>I am reviewing your patch.
>> Is the patch in context diff format?
>>Yes.
>
>Thanks for reviewing the patch.
>
>> Does it apply cleanly to the current git master?
>>Not quite cleanly but it d
Hello,
I'm trying to print out the tuples in the b-tree nodes for analysis,
but when iterate over more than the first entry of the tuples
(scanKey++), I strangely get the error below on query execution:
ERROR: relation "simpletest" does not exist
LINE 1: SELECT * FROM simpletest WHERE id = 50
Hello
What is state of this issue?
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00423.php
We detect this issue in our servers - we use 9.1.6 on Linux
locktype | database | relation | page | tuple | virtualxid |
transactionid | classid | objid | objsubid | virtualtransaction | pid
|
On Mon, Dec 10, 2012 at 11:21 PM, Jeff Davis wrote:
>
> And I have a few other questions/comments:
>
> * Why is "summ" spelled with two "m"s? Is it short for "summation"? If
> so, might be good to use "summation of" instead of "integrate" in the
> comment.
>
Fixed.
> * Why does get_length_hist_
40 matches
Mail list logo
