From: | Cédric Villemain <cedric(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Proposed patch: remove hard-coded limit MAX_ALLOCATED_DESCS |
Date: | 2013-06-08 20:01:22 |
Message-ID: | 201306082201.22931.cedric@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > I just wonder about this statement that you removed:
> > * Since we don't want to encourage heavy use of those functions,
> > * it seems OK to put a pretty small maximum limit on the number of
> > * simultaneously allocated descs.
>
> > Is it now encouraged to use those functions, or at least that it seems less
> > 'scary' than in the past ?
>
> Well, we could put back some weaker form of the statement, but I wasn't
> sure how to word it.
I'm not sure of the 'expected' problems...
The only thing I can think of at the moment is the time spent to close
file descriptors on abort/commit.
I'm not sure of expected value of "max_safe_fds". Your patch now initialize
with 5 slots instead of 10, if max_safe_fds is large maybe it is better to
double the size each time we need instead of jumping directly to the largest
size ?
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2013-06-08 20:13:37 | Re: Redesigning checkpoint_segments |
Previous Message | Greg Smith | 2013-06-08 19:31:13 | Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) |