On Fri, Apr 29, 2016 at 7:08 AM, Bruce Momjian wrote:
> On Wed, Apr 6, 2016 at 12:57:16PM +0200, Andres Freund wrote:
>> While benchmarking on hydra
>> (c.f.
>> http://archives.postgresql.org/message-id/20160406104352.5bn3ehkcsceja65c%40alap3.anarazel.de),
>> which has quite slow IO, I was once
On Wed, Apr 6, 2016 at 12:57:16PM +0200, Andres Freund wrote:
> Hi,
>
> While benchmarking on hydra
> (c.f.
> http://archives.postgresql.org/message-id/20160406104352.5bn3ehkcsceja65c%40alap3.anarazel.de),
> which has quite slow IO, I was once more annoyed by how incredibly long
> the vacuum at
On Thu, Apr 14, 2016 at 10:22 AM, Peter Geoghegan wrote:
>
> On Tue, Apr 12, 2016 at 11:38 AM, Andres Freund
wrote:
> >> And, on the other hand, if we don't do something like that, it will be
> >> quite an exceptional case to find anything on the free list. Doing it
> >> just to speed up develop
On Tue, Apr 12, 2016 at 11:38 AM, Andres Freund wrote:
>
>> The bottom line
>> here, IMHO, is not that there's anything wrong with our ring buffer
>> implementation, but that if you run PostgreSQL on a system where the
>> I/O is hitting a 5.25" floppy (not to say 8") the performance may be
>> le
On Tue, Apr 12, 2016 at 11:38 AM, Andres Freund wrote:
>> And, on the other hand, if we don't do something like that, it will be
>> quite an exceptional case to find anything on the free list. Doing it
>> just to speed up developer benchmarking runs seems like the wrong
>> idea.
>
> I don't think
On Wed, Apr 13, 2016 at 12:08 AM, Andres Freund wrote:
>
> On 2016-04-12 14:29:10 -0400, Robert Haas wrote:
> > On Wed, Apr 6, 2016 at 6:57 AM, Andres Freund
wrote:
> > > While benchmarking on hydra
> > > (c.f.
http://archives.postgresql.org/message-id/20160406104352.5bn3ehkcsceja65c%40alap3.anar
On 2016-04-13 06:57:15 -0400, Robert Haas wrote:
> You will eventually, because each scan will pick a new ring buffer,
> and gradually more and more of the relation will get cached. But it
> can take a while.
You really don't need much new data to make that an unobtainable goal
... :/
> I'd be
On Tue, Apr 12, 2016 at 2:38 PM, Andres Freund wrote:
>> And, on the other hand, if we don't do something like that, it will be
>> quite an exceptional case to find anything on the free list. Doing it
>> just to speed up developer benchmarking runs seems like the wrong
>> idea.
>
> I don't think
Robert, Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-04-12 14:29:10 -0400, Robert Haas wrote:
> > On Wed, Apr 6, 2016 at 6:57 AM, Andres Freund wrote:
> > That does not seem like a good idea from here. One of the ideas I
> > still want to explore at some point is having a backgr
On 2016-04-12 14:29:10 -0400, Robert Haas wrote:
> On Wed, Apr 6, 2016 at 6:57 AM, Andres Freund wrote:
> > While benchmarking on hydra
> > (c.f.
> > http://archives.postgresql.org/message-id/20160406104352.5bn3ehkcsceja65c%40alap3.anarazel.de),
> > which has quite slow IO, I was once more annoye
On Wed, Apr 6, 2016 at 6:57 AM, Andres Freund wrote:
> While benchmarking on hydra
> (c.f.
> http://archives.postgresql.org/message-id/20160406104352.5bn3ehkcsceja65c%40alap3.anarazel.de),
> which has quite slow IO, I was once more annoyed by how incredibly long
> the vacuum at the the end of a p
Hi,
While benchmarking on hydra
(c.f.
http://archives.postgresql.org/message-id/20160406104352.5bn3ehkcsceja65c%40alap3.anarazel.de),
which has quite slow IO, I was once more annoyed by how incredibly long
the vacuum at the the end of a pgbench -i takes.
The issue is that, even for an entirely s
12 matches
Mail list logo
