Hello monters and hackers,
This is a late summary of pg performance farm in gsoc. Although it is not
yet perfect, but it has began to take shape.
1. The implementation of the basic test results upload interface to ensure
that the upload operation for the atomic level (including different client
On 17 August 2018 at 04:01, Alvaro Herrera wrote:
> Looks good, pushed. I edited the comment a little bit.
Thanks for pushing.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Sun, Aug 19, 2018 at 4:28 PM, Masayuki Takahashi
wrote:
>> If you just supply an IsForeignScanParallelSafe function that returns
>> true, that would allow your FDW to be used inside parallel workers and
>> wouldn't need any extra shared memory, but it wouldn't be a "parallel
>> scan". It
On Tue, Aug 14, 2018 at 06:53:32PM +0200, Michael Paquier wrote:
> I was thinking about adding "Even if it is not atomic" or such at the
> beginning of the paragraph, but at the end your phrasing sounds better
> to me. So I have hacked up the attached, which also reworks the comment
> in
On 14 August 2018 at 04:00, Robert Haas wrote:
> I've thought about similar things, but I think there's a pretty deep
> can of worms. For instance, if you built a relcache entry using the
> transaction snapshot, you might end up building a seemingly-valid
> relcache entry for a relation that has
I wrote:
> [ snprintf-speedups-1.patch ]
Here's a slightly improved version of that, with two changes:
* Given the current state of the what-about-%m thread, it's no longer
academic how well this performs relative to glibc's version. I poked
at that and found that a lot of the discrepancy came
On Fri, Aug 03, 2018 at 02:08:27PM +0100, Alexandra Ryzhevich wrote:
> Thank you for pointing to some problems of the patch. I've attached a
> modified version below.
Could you avoid top-posting? This is not the style of the Postgres
mailing lists.
I have been looking at your latest patch, and
On Sat, Apr 7, 2018 at 1:03 AM, Julian Markwort
wrote:
> I've created a draft patch that provides access to plans in a view called
> pg_stat_statements_plans.
> There is no column that indicates whether the plan is "good" or "bad",
> because that is evident from the execution time of both plans
I wrote:
>> Consider the following approach:
>> 1. Teach src/port/snprintf.c about %m. While I've not written a patch
>> for this, it looks pretty trivial.
>> 2. Teach configure to test for %m and if it's not there, use the
>> replacement snprintf. (Note: we're already forcing snprintf
> On Aug 18, 2018, at 11:59 PM, Alvaro Herrera wrote:
>
> On 2018-Aug-18, Jonathan S. Katz wrote:
>
>>
>>> On Aug 18, 2018, at 8:52 PM, Jonathan S. Katz wrote:
>>>
On Aug 18, 2018, at 8:45 PM, Michael Paquier wrote:
I am not so sure about v11 as it is very close to
On 2018-Aug-19, Hongyuan Ma wrote:
> Hello monters and hackers,
Is that "monsters" or "mentors"?
> 2. Implementation of the data report related to the list page. Compare each
> metrics whith the previous results. If any of the metrics are a 5%
> improvement( or regression), there is one aspect
On Sun, Aug 19, 2018 at 01:15:58AM -0400, Tom Lane wrote:
> Nico Williams writes:
> > On Sat, Aug 18, 2018 at 04:34:50PM -0400, Tom Lane wrote:
> >> So now I'm about ready to propose that we just *always* use
> >> snprintf.c, and forget all of the related configure probing.
>
> > You'd also get
On Fri, Jul 13, 2018 at 11:05:10AM +0200, Peter Eisentraut wrote:
> After reviewing that thread, I think my patch would still be relevant.
> Because the pending proposal is to not add TOAST tables to some catalogs
> such as pg_attribute, so my original use case of allowing ALTER TABLE /
> SET on
On Thu, Mar 08, 2018 at 02:13:51PM -0500, Peter Eisentraut wrote:
> In the thread about Secure Transport we agreed to move the consideration
> of new SSL libraries to PG12.
>
> Here is my current patch, after all the refactorings.
>
> The status is that it works fine and could be used.
>
>
On August 18, 2018 10:52:33 AM GMT+09:00, Tom Lane wrote:
I think it probably needs to stay documented, but we could mark it as
deprecated ...
Okay, no issues with doing so.
I revised the patch like following:
vacuumlo:
Document
- Add long options
- Add environment section
On Mon, Aug 20, 2018 at 12:30:29PM +0900, Tatsuro Yamada wrote:
> vacuumlo:
>Document
> - Add long options
> - Add environment section
Let's keep things simple by not adding long options where it is not
especially obvious, so I would suggest to keep the patch simple and just
add
On Mon, Aug 20, 2018 at 2:55 PM, Tom Lane wrote:
> Thomas Munro writes:
> As previously noted, that seems like a nice thing to allow ...
>
>> + pgssPlan *planArray[numPlans];
>> Can't use variable length arrays in C89.
>
> ... but I'm less excited about this one. Seems like a great opportunity
On Mon, Aug 20, 2018 at 04:38:20PM +1200, Thomas Munro wrote:
> "For examples of usage look at simplehash.c ..."
>
> There is no such file in the tree. Maybe this should say tidbitmap.c?
And execGrouping.c..
--
Michael
signature.asc
Description: PGP signature
Thomas Munro writes:
> On Mon, Aug 20, 2018 at 2:55 PM, Tom Lane wrote:
>> Can we prevent that from being allowed,
>> if we start using -std=c99?
> -Werror=vla in GCC, apparently.
Ah, cool.
> Another problem with VLAs is that they aren't in C++ and last I heard
> they aren't ever likely to be
On Fri, Aug 10, 2018 at 04:50:55PM -0400, Tom Lane wrote:
> I would certainly *not* back-patch the GetConfigOptionByNum change,
> as that will be a user-visible behavioral change that people will
> not be expecting. We might get away with back-patching the other changes,
> but SHOW ALL output
On Tue, Aug 14, 2018 at 01:38:23PM +0900, Masahiko Sawada wrote:
> On Thu, Jul 12, 2018 at 9:28 PM, Masahiko Sawada
> wrote:
>> Attached new version of patch incorporated the all comments I got from
>> Michael-san.
>>
>> To prevent the WAL segment file of restart_lsn of the origin slot from
>>
[ off topic for this patch, but as long as you mentioned switching
to C99 ]
Thomas Munro writes:
> + for(int j = 0; j < numPlans; j++)
> Can't declare a new variable here in C89.
As previously noted, that seems like a nice thing to allow ...
> + pgssPlan *planArray[numPlans];
> Can't use
Hi,
"For examples of usage look at simplehash.c ..."
There is no such file in the tree. Maybe this should say tidbitmap.c?
--
Thomas Munro
http://www.enterprisedb.com
23 matches
Mail list logo
