| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Decrease MAX_BACKENDS to 2^16 |
| Date: | 2014-04-26 15:20:56 |
| Message-ID: | 21785.1398525656@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-04-26 11:52:44 +0100, Greg Stark wrote:
>> But I don't think it's beyond the realm of possibility
>> that we'll reduce the overhead in the future with an eye to being able
>> to do that. Is it that helpful that it's worth baking in more
>> dependencies on that limitation?
> What I think it's necessary for is at least:
> * Move the buffer content lock inline into to the buffer descriptor,
> while still fitting into one cacheline.
> * lockless/atomic Pin/Unpin Buffer.
TBH, that argument seems darn weak, not to mention probably applicable
only to current-vintage Intel chips. And you have not proven that
narrowing the backend ID is necessary to either goal, even if we
accepted that these goals were that important.
While I agree with you that it seems somewhat unlikely we'd ever get
past 2^16 backends, these arguments are not nearly good enough to
justify a hard-wired limitation.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-04-26 15:22:39 | Re: Decrease MAX_BACKENDS to 2^16 |
| Previous Message | Tom Lane | 2014-04-26 15:16:01 | Re: Problem with displaying "wide" tables in psql |