Hi,
On 2017-10-13 10:38:47 -0700, Andres Freund wrote:
> On 2017-10-13 13:06:41 -0400, Robert Haas wrote:
> > On Thu, Sep 14, 2017 at 2:12 AM, Andres Freund wrote:
> > > This patch gives me roughly 8% speedup in a workload that consists out
> > > of a fast query that returns a lot of columns. If
Andres Freund writes:
> On 2017-10-13 14:07:54 -0400, Tom Lane wrote:
>> One idea might be to see if we can precalculate all the control data
>> needed for the caches and set it up as compile-time constants,
>> a la Gen_fmgrtab.pl, rather than reading it from the catalogs during
>> startup. That
On 2017-10-13 14:07:54 -0400, Tom Lane wrote:
> One idea might be to see if we can precalculate all the control data
> needed for the caches and set it up as compile-time constants,
> a la Gen_fmgrtab.pl, rather than reading it from the catalogs during
> startup. That would make the code less depe
Andres Freund writes:
> On 2017-10-13 13:06:41 -0400, Robert Haas wrote:
>> I don't think it's this patch's job to do it, but it seems like we
>> ought to just invent some early-initialization step where things like
>> this can happen, so that we don't have to branch here at all.
> Yea, that'd be
Hi,
On 2017-10-13 13:06:41 -0400, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 2:12 AM, Andres Freund wrote:
> > This patch gives me roughly 8% speedup in a workload that consists out
> > of a fast query that returns a lot of columns. If I apply a few
> > other performance patches, this patch it
On Thu, Sep 14, 2017 at 2:12 AM, Andres Freund wrote:
> This patch gives me roughly 8% speedup in a workload that consists out
> of a fast query that returns a lot of columns. If I apply a few
> other performance patches, this patch itself starts to make a bigger
> difference, of around 11%.
I d
On 09/26/2017 06:41 AM, tushar wrote:
On 09/22/2017 11:45 AM, Andres Freund wrote:
Here's a variant that cleans up the previous changes a bit, and adds
some further improvements:
I tested with different pgbench options with master v/s patch and found
an improvement. I have applied 001 and 0
On Fri, Sep 22, 2017 at 11:47 AM, Andres Freund wrote:
> Hi,
>
> On 2017-09-20 18:26:50 +0530, amul sul wrote:
> > Patch 0007:
>
> Other than these concern, patch looks pretty reasonable to me.
>
> I'd appreciate if you could have a look at the new version as well.
>
>
I have reviewed
the new
On 09/22/2017 11:45 AM, Andres Freund wrote:
Here's a variant that cleans up the previous changes a bit, and adds
some further improvements:
I tested with different pgbench options with master v/s patch and found an
improvement. I have applied 001 and 003 patch on PG Head ,patch 0002 was
al
On Fri, Sep 22, 2017 at 2:15 AM, Andres Freund wrote:
> This results in making cache lookups themselves roughly three times as
> fast - full-system benchmarks obviously improve less than that.
Wow. That's really good.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
Hi,
On 2017-09-20 18:26:50 +0530, amul sul wrote:
> Patch 0007:
Thanks for looking!
> 1:
> 400 + /*
> 401 +* XXX: might be worthwhile to only handle oid sysattr, to
> reduce
> 402 +* overhead - it's the most common key.
> 403 +*/
>
> IMHO, let fix that as well. I t
Hi,
On 2017-09-13 23:12:07 -0700, Andres Freund wrote:
> Attached is a patch that tries to improve sys/catcache performance,
> going further than the patch referenced earlier.
Here's a variant that cleans up the previous changes a bit, and adds
some further improvements:
Here's the main commit m
Patch 0007:
1:
400 + /*
401 +* XXX: might be worthwhile to only handle oid sysattr, to
reduce
402 +* overhead - it's the most common key.
403 +*/
IMHO, let fix that as well. I tested this by fixing (see the attach patch)
but does
not found much gain on my local cento
13 matches
Mail list logo