Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Egor Rogov (e.ro...@postgrespro.ru) wrote:
> > On 11.02.2021 01:10, Stephen Frost wrote:
> > >* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > >>On 05/02/2021 23:22, Stephen Frost wrote:
> > >>>Unless there's anything else on this, I'll c
Greetings,
* Justin Pryzby (pry...@telsasoft.com) wrote:
> This patch adds hits/misses/dirtied, but explain says
> hit/read/dirtied/written.
>
> Should it say "read" instead of "misses" ?
>
> src/backend/access/heap/vacuumlazy.c:
>_("buffer u
This patch adds hits/misses/dirtied, but explain says hit/read/dirtied/written.
Should it say "read" instead of "misses" ?
src/backend/access/heap/vacuumlazy.c:
_("buffer usage: %lld hits, %lld misses, %lld dirtied\n"),
src/backend/commands/exp
Greetings,
* Egor Rogov (e.ro...@postgrespro.ru) wrote:
> On 11.02.2021 01:10, Stephen Frost wrote:
> >* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> >>On 05/02/2021 23:22, Stephen Frost wrote:
> >>>Unless there's anything else on this, I'll commit these sometime next
> >>>week.
> >>One more thin
Hi,
On 11.02.2021 01:10, Stephen Frost wrote:
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
On 05/02/2021 23:22, Stephen Frost wrote:
Unless there's anything else on this, I'll commit these sometime next
week.
One more thing: Instead of using 'effective_io_concurrency' GUC direct
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> > >> I think e.g. prefetch_targblock could be moved to the next #ifdef, which
> > >> will eliminate the one-line ifdef.
> > >
> > > Sure, done in the attached.
> > >
> > > Thanks for the review! Unless there's other comments, I'll plan to
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> On 3/12/21 1:11 AM, Stephen Frost wrote:
> > * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> >> On 3/8/21 8:42 PM, Stephen Frost wrote:
> >>> * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> On 2/10/21 11:10 PM,
On 3/12/21 1:11 AM, Stephen Frost wrote:
> Greetings,
>
> * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
>> On 3/8/21 8:42 PM, Stephen Frost wrote:
>>> * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
On 2/10/21 11:10 PM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinn..
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> On 3/8/21 8:42 PM, Stephen Frost wrote:
> > * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> >> On 2/10/21 11:10 PM, Stephen Frost wrote:
> >>> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 05/02/2021 23:22, Stephe
On 3/8/21 8:42 PM, Stephen Frost wrote:
> Greetings,
>
> * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
>> On 2/10/21 11:10 PM, Stephen Frost wrote:
>>> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
On 05/02/2021 23:22, Stephen Frost wrote:
> Unless there's anything else on this, I
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> On 2/10/21 11:10 PM, Stephen Frost wrote:
> > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> >> On 05/02/2021 23:22, Stephen Frost wrote:
> >>> Unless there's anything else on this, I'll commit these sometime next
> >>> week.
> >>
Hi,
On 2/10/21 11:10 PM, Stephen Frost wrote:
> Greetings,
>
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> On 05/02/2021 23:22, Stephen Frost wrote:
>>> Unless there's anything else on this, I'll commit these sometime next
>>> week.
>>
>> One more thing: Instead of using 'effective_io_concur
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 05/02/2021 23:22, Stephen Frost wrote:
> >Unless there's anything else on this, I'll commit these sometime next
> >week.
>
> One more thing: Instead of using 'effective_io_concurrency' GUC directly,
> should call get_tablespace_mainten
On 05/02/2021 23:22, Stephen Frost wrote:
Unless there's anything else on this, I'll commit these sometime next
week.
One more thing: Instead of using 'effective_io_concurrency' GUC
directly, should call get_tablespace_maintenance_io_concurrency().
- Heikki
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 13/01/2021 23:17, Stephen Frost wrote:
> >Would be great to get a review / comments from others as to if there's
> >any concerns. I'll admit that it seems reasonably straight-forward to
> >me, but hey, I wrote most of it, so that's not
On 13/01/2021 23:17, Stephen Frost wrote:
Would be great to get a review / comments from others as to if there's
any concerns. I'll admit that it seems reasonably straight-forward to
me, but hey, I wrote most of it, so that's not really a fair
assessment... ;)
Look good overall. A few minor co
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> > Thanks. I'll do some testing/benchmarking once my machines are free, in
> > a couple days perhaps. But as I said before, I don't expect this to
> > behave very differently from other
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> Thanks. I'll do some testing/benchmarking once my machines are free, in
> a couple days perhaps. But as I said before, I don't expect this to
> behave very differently from other places that already do prefetching.
Agreed, but wou
On 11/9/20 7:06 PM, Stephen Frost wrote:
> Greetings,
>
> * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
>> On 11/4/20 5:02 PM, Stephen Frost wrote:
>>> * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> If you highlight "738754560" in the output it appears to duplicate the
> sys
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On 11/4/20 5:02 PM, Stephen Frost wrote:
> >* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> >>>If you highlight "738754560" in the output it appears to duplicate the
> >>>syscalls issued until it preads() - in case of "738754
Hi,
On 11/4/20 5:02 PM, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
If you highlight "738754560" in the output it appears to duplicate the
syscalls issued until it preads() - in case of "738754560" offset it was
asked for 3 times. Also I wouldn't imagi
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> >If you highlight "738754560" in the output it appears to duplicate the
> >syscalls issued until it preads() - in case of "738754560" offset it was
> >asked for 3 times. Also I wouldn't imagine in wildest dreams that
> >posix_fadvi
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Wed, Nov 04, 2020 at 09:07:59AM +, Jakub Wartak wrote:
> >I saw up 410MB/s for a few seconds with this patch on NVMe, and that's
> >huge ~5.2x improvement which is amazing for a such simple patch.
Nice!
> >The system and da
On Wed, Nov 04, 2020 at 09:07:59AM +, Jakub Wartak wrote:
Greetings Stephen,
I saw up 410MB/s for a few seconds with this patch on NVMe, and that's
huge ~5.2x improvement which is amazing for a such simple patch.
The system and data was identical like last time, so results are directly
co
e in wildest dreams that
posix_fadvise(POSIX_FADV_WILLNEED) is such a cheap syscall.
-J.
From: Stephen Frost
Sent: Tuesday, November 3, 2020 6:47 PM
To: Jakub Wartak
Cc: pgsql-hackers
Subject: Re: automatic analyze: readahead - add "IO read time" log me
Greetings,
* Jakub Wartak (jakub.war...@tomtom.com) wrote:
> >Interesting that you weren't seeing any benefit to disabling readahead.
>
> I've got some free minutes and I have repeated the exercise in more realistic
> and strict environment that previous one to conclude that the current
> situat
Hi Stephen, hackers,
>> > With all those 'readahead' calls it certainly makes one wonder if the
>> > Linux kernel is reading more than just the block we're looking for
>> > because it thinks we're doing a sequential read and will therefore want
>> > the next few blocks when, in reality, we're goin
Greetings Jakub,
* Jakub Wartak (jakub.war...@tomtom.com) wrote:
> > The analyze is doing more-or-less random i/o since it's skipping through
> > the table picking out select blocks, not doing regular sequential i/o.
> VS
> >> Breakpoint 1, heapam_scan_analyze_next_block (scan=0x10c8098,
> >> blo
Hi Stephen, hackers,
> The analyze is doing more-or-less random i/o since it's skipping through
> the table picking out select blocks, not doing regular sequential i/o.
VS
>> Breakpoint 1, heapam_scan_analyze_next_block (scan=0x10c8098,
>> blockno=19890910, bstrategy=0x1102278) at heapam_handler.
Greetings,
* Jakub Wartak (jakub.war...@tomtom.com) wrote:
> I have I hope interesting observation (and nano patch proposal) on system
> where statistics freshness is a critical factor. Autovacuum/autogathering
> statistics was tuned to be pretty very aggressive:
> autovacuum_vacuum_cost_delay=0
Greetings hackers,
I have I hope interesting observation (and nano patch proposal) on system where
statistics freshness is a critical factor. Autovacuum/autogathering statistics
was tuned to be pretty very aggressive:
autovacuum_vacuum_cost_delay=0 (makes autovacuum_vacuum_cost_limit irrelevant)
31 matches
Mail list logo
