On Tue, 2024-09-03 at 10:39 +0530, veem v wrote:
> As you rightly said "they will make it more difficult to detach a partition."
> ,
> we are really seeing a longer time when detaching parent table partitions.
> It runs forever sometimes. So do you mean it's because we have primary key
> defined t
On Tue, 3 Sept 2024 at 01:14, Laurenz Albe wrote:
>
> You can keep the primary key defined on both columns if it is good enough
> for you.
> But it will give you lower guarantees of uniqueness: with that primary
> key, there could
> be two rows with a different timestamp, but the same "txn_id", a
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, 2024-09-02 at 21:39 +0530, veem v wrote:
> On Mon, 2 Sept 2024 at 19:13, Laurenz Albe wrote:
> > On Sun, 2024-09-01 at 01:32 +0530, veem v wrote:
> > > due to postgres limitations we are unable to have this unique constraint
> > > or primary key
> > > only on the transaction_id column, we
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 Mon, 2 Sept 2024 at 19:13, Laurenz Albe wrote:
> On Sun, 2024-09-01 at 01:32 +0530, veem v wrote:
> > due to postgres limitations we are unable to have this unique constraint
> or primary key
> > only on the transaction_id column, we have to include
> transaction_timestamp with it as
> > a com
On Sun, 2024-09-01 at 01:32 +0530, veem v wrote:
> due to postgres limitations we are unable to have this unique constraint or
> primary key
> only on the transaction_id column, we have to include transaction_timestamp
> with it as
> a composite key. So I want to understand from experts if there
Hi Muhammad,
On Mon, 2 Sep 2024, 09:45 Muhammad Ikram, wrote:
> Hi Shaheed,
> I think you must have already analyzed the outcome of queries
> on pg_replication_slots, pg_current_wal_lsn(), pg_stat_subscription etc. I
> could find a query SELECT
> pg_size_pretty(pg_wal_lsn_diff('',
> ''));
>
Ye
Hi Shaheed,
I think you must have already analyzed the outcome of queries
on pg_replication_slots, pg_current_wal_lsn(), pg_stat_subscription etc. I
could find a query SELECT
pg_size_pretty(pg_wal_lsn_diff('',
''));
As a side note if you want to see what has been applied to subscribers vs
what ex
Hi Muhammad,
On Mon, 2 Sep 2024, 07:08 Muhammad Ikram, wrote:
> Hi Shaheed,
>
> Maybe these considerations could help you or give any hint to the problem ?
>
>
> Check if wal_receiver_timeout being set to 0 could potentially cause
> issues, like not detecting network issues quickly enough. Consi
19 matches
Mail list logo
