On Tue, May 24, 2016 at 11:34 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Jeff Janes writes:
>> > commit 1aba62ec made zero be an illegal value for effective_io_concurrency.
>> > i think this was an accident. If not, then the sample postgresql.conf
>> > (at least) needs to be updated.
>>
>> I
Tom Lane wrote:
> Jeff Janes writes:
> > commit 1aba62ec made zero be an illegal value for effective_io_concurrency.
> > i think this was an accident. If not, then the sample postgresql.conf
> > (at least) needs to be updated.
>
> It looks like the problem is that the new range check
>
> + /*
Jeff Janes writes:
> commit 1aba62ec made zero be an illegal value for effective_io_concurrency.
> i think this was an accident. If not, then the sample postgresql.conf
> (at least) needs to be updated.
It looks like the problem is that the new range check
+ /* This range check shouldn't fail
commit 1aba62ec made zero be an illegal value for effective_io_concurrency.
i think this was an accident. If not, then the sample postgresql.conf
(at least) needs to be updated.
Cheers,
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
On Mon, Sep 29, 2014 at 10:41 AM, Peter Eisentraut wrote:
> I think this is a mistake. For example, we allow setting ssl to false
> even if SSL support is not compiled in.
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
The documentation of effective_io_concurrency says
Asynchronous I/O depends on an effective posix_fadvise
function, which some operating systems lack. If the function is not
present then setting this parameter to anything but zero will result
in an error.
This is not correct, bec
On Thu, Aug 30, 2012 at 1:25 PM, Peter Geoghegan wrote:
> Just how helpful is effective_io_concurrency? Did someone produce a
> benchmark at some point?
Attached is a benchmark I put together a while ago.
I don't know how close to "real world" it might be. I haven't seen it
in the wild, but I'
On 30 August 2012 20:28, Robert Haas wrote:
> On Sat, Jul 28, 2012 at 4:09 PM, Jeff Janes wrote:
>> But it might be better yet to make ordinary index scans benefit from
>> effective_io_concurrency, but even if/when that gets done it would
>> probably still be worthwhile to make the planner unders
On Sat, Jul 28, 2012 at 4:09 PM, Jeff Janes wrote:
> From my attempted reading of the thread "posix_fadvise v22", it seems
> like modification of the planner was never discussed, rather than
> being discussed and rejected. So, is there a reason not to make the
> planner take account of effective_
The bitmap heap scan can benefit quite a bit from
effective_io_concurrency on RAID system (and to some extent even on
single spindle systems)
However, the planner isn't aware of this. So you have to just be
lucky to have it choose the bitmap heap scan instead of something else
that can't benefit
10 matches
Mail list logo
