On 03/09/2024 10:34, Pavel Luzanov wrote:
On 03.09.2024 00:11, Heikki Linnakangas wrote:
Pavel, did you test v17 with checksums enabled and v16 with checksums
disabled, by any chance?
Exactly, You are right!
My v16 cluster comes from the default Ubuntu distribution.
I forgot that checksums di
On 03.09.2024 00:11, Heikki Linnakangas wrote:
Pavel, did you test v17 with checksums enabled and v16 with checksums
disabled, by any chance?
Exactly, You are right!
My v16 cluster comes from the default Ubuntu distribution.
I forgot that checksums disabled by default.
But when I initialize th
On 03/09/2024 00:11, Heikki Linnakangas wrote:
On 03/09/2024 00:01, Peter Geoghegan wrote:
On Mon, Sep 2, 2024 at 4:58 PM Heikki Linnakangas
wrote:
Do you have any non-default settings? "select name,
current_setting(name), source from pg_settings where setting <>
boot_val;" would show that.
On Mon, Sep 2, 2024 at 4:58 PM Peter Geoghegan wrote:
> On Mon, Sep 2, 2024 at 4:35 PM Pavel Luzanov wrote:
> > If it helps, without creating index on id column, the numbers will be
> > much closer:
>
> Yes, avoiding all index vacuuming seems useful. It makes the test case
> cleaner, since we don
On 03/09/2024 00:01, Peter Geoghegan wrote:
On Mon, Sep 2, 2024 at 4:58 PM Heikki Linnakangas wrote:
Do you have any non-default settings? "select name,
current_setting(name), source from pg_settings where setting <>
boot_val;" would show that.
What about page checksums?
One simple explanat
On Mon, Sep 2, 2024 at 4:58 PM Heikki Linnakangas wrote:
> Do you have any non-default settings? "select name,
> current_setting(name), source from pg_settings where setting <>
> boot_val;" would show that.
What about page checksums?
One simple explanation is that we're writing extra FPIs to se
On Mon, Sep 2, 2024 at 4:35 PM Pavel Luzanov wrote:
> If it helps, without creating index on id column, the numbers will be
> much closer:
Yes, avoiding all index vacuuming seems useful. It makes the test case
cleaner, since we don't have to think about the variability from the
TIDStore work (and
On 02/09/2024 23:35, Pavel Luzanov wrote:
On 02.09.2024 22:23, Melanie Plageman wrote:
For some reason I stopped being able to reproduce Pavel's case.
I also cannot reproduce this.
I repeated the test on another computer, but compared master with v15.
The results are the same. The test can b
On 02.09.2024 22:23, Melanie Plageman wrote:
For some reason I stopped being able to reproduce Pavel's case.
I repeated the test on another computer, but compared master with v15.
The results are the same. The test can be simplified as follows:
CREATE TABLE t(id integer) WITH (autovacuum_enabl
On Mon, Sep 2, 2024 at 3:23 PM Melanie Plageman
wrote:
> This is roughly what I get for records by vacuum. Note that I prefixed
> VACUUM with BTREE on master to indicate those records are from index
> vacuuming. By default the headesc routine for records emitted by index
> vacuuming prints just VA
On Mon, Sep 2, 2024 at 1:47 PM Peter Geoghegan wrote:
>
> On Mon, Sep 2, 2024 at 1:29 PM Melanie Plageman
> wrote:
> > I'll investigate more tomorrow, but based on my initial investigation,
> > there appears to be some interaction related to how much of the
> > relation is in shared buffers after
On Mon, Sep 2, 2024 at 1:29 PM Melanie Plageman
wrote:
> I'll investigate more tomorrow, but based on my initial investigation,
> there appears to be some interaction related to how much of the
> relation is in shared buffers after creating the table and updating
> it. If you set shared_buffers su
On Sun, Sep 1, 2024 at 6:00 PM Peter Geoghegan wrote:
>
> On Sun, Sep 1, 2024 at 5:44 PM Pavel Luzanov wrote:
> > I see a perfectly working TID-store optimization.
> > With reduced maintenance_work_mem it used only one 'vacuuming indexes'
> > phase instead of 21 in v16.
> > But I also expected to
On Sun, Sep 1, 2024 at 5:44 PM Pavel Luzanov wrote:
> I see a perfectly working TID-store optimization.
> With reduced maintenance_work_mem it used only one 'vacuuming indexes'
> phase instead of 21 in v16.
> But I also expected to see a reduction in the number of WAL records
> and the total size
14 matches
Mail list logo
