which can thus be around 100% of a
table in the least efficient cases of having a PK over all columns.
Yes, this might be indeed only a 'small gain' for access latency, but
not needing to store another copy of your data (and keeping it in
cache, etc.) is a significant win in my book.
Regarding losing deduplication in btrees when we have varlena TIDs:
This loss in [storage] efficiency can be partially mitigated by
implementing prefix truncation/prefix deduplication, and as such that
loss would not necessarily be too problematic when PT/PD is
implemented.
With regards,
Matthias van de Meent
imilar level to the deduplication of constaint
indexes.
With regards,
Matthias van de Meent
+ to identify tuple versions.
With regards,
Matthias van de Meent.
only doing so in the 2nd VACUUM
pass. This is especially relevant on pages where hot is highly
effective, but vacuum can't keep up and many unused (former HOT) line
pointers now exist on the page.
With regards,
Matthias van de Meent
that breaks more things than otherwise required. ip_posid is
already limited to uint16, so I see no reason to add a constant that would
assert that the value of any uint16 is less its max value plus one.
With regards,
Matthias van de Meent
On Sat, 17 Apr 2021 at 01:05, Peter Geoghegan wrote:
>
> On Fri, Apr 16, 2021 at 2:20 PM Matthias van de Meent
> wrote:
> > > Interesting approach. I think that in an ideal world we would have a
> > > tuple format with attribute lengths/offsets right in th
On Fri, 16 Apr 2021 at 18:03, Peter Geoghegan wrote:
>
> On Thu, Apr 15, 2021 at 11:06 AM Matthias van de Meent
> wrote:
> > I've noticed there are a lot of places in the btree index
> > infrastructure (and also some other index AMs) that effectively
> > iterate over
On Thu, 15 Apr 2021 at 21:24, Justin Pryzby wrote:
>
> On Thu, Apr 15, 2021 at 08:47:26PM +0200, Matthias van de Meent wrote:
> > I recently noticed that ATTACH PARTITION also recursively locks the
> > default partition with ACCESS EXCLUSIVE mode when its constraints do
> >
just that.
With regards,
Matthias van de Meent.
From 2bf23cd8018c7e2cbff4f00be4aba1e806750998 Mon Sep 17 00:00:00 2001
From: Matthias van de Meent
Date: Thu, 15 Apr 2021 20:43:00 +0200
Subject: [PATCH v1] ATTACH PARTITION locking documentation for DEFAULT
partitions.
---
doc/src/sgml/ddl.sgml
lightly disappointed with the results of the always_null
insert load; I had hoped for better results there, seeing the results
for the other 2 multi-column indexes.
With regards,
Matthias van de Meent.
[0]
https://www.postgresql.org/message-id/cah2-wzn_nayk4pr0hrwo0stwhmxjp5qyu+x8vppt030xpqr.
h regards to number of
committed patches registered to one CF.
> Today and tomorrow I'll be checking the Waiting on Author patches to
> determine which should be moved to the next CF and which should be
> returned with feedback. The rest will be moved to the next CF when this
> one is closed.
I noticed that there is an old patch stuck at 'Needs review' in CF
2020-09. Could you also update the state of that patch, because I
don't think I am the right person to do that.
With regards,
Matthias van de Meent
On Tue, 6 Apr 2021 at 05:13, Peter Geoghegan wrote:
>
> On Mon, Apr 5, 2021 at 2:44 PM Matthias van de Meent
> wrote:
> > This assertion is false, and should be a guarding if-statement. HOT
> > redirect pointers are not updated if the tuple they're pointing to is
&g
t; Attached is the updated version of the patch. Barring any objection,
> I'm thinking to commit this.
Thanks, this was on my to-do list for today, but you were faster.
No objections on my part, and thanks for picking this up.
With regards,
Matthias van de Meent
t quite make it clear what its relationship
is with autovacuum_freeze_max_age. How about the following: "...
>VACUUM< will use the higher of this value and 105% of
>guc-autovacuum-freeze-max-age<, so that only ...". It's only slightly
easier to read, but at least it conveys that values lower than 105% of
autovacuum_freeze_max_age are not considered. The same can be said for
the multixact guc documentation.
With regards,
Matthias van de Meent
On Wed, 31 Mar 2021 at 05:35, Peter Geoghegan wrote:
>
> On Wed, Mar 10, 2021 at 6:01 AM Matthias van de Meent
> wrote:
> > > The case I was concerned about back when is that there are various bits of
> > > code that may visit a page with a predetermined TID in mind
On Mon, 29 Mar 2021 at 14:33, Daniel Verite wrote:
>
> Matthias van de Meent wrote:
>
> > The results for the Japanese locale should be "0003 Reiwa" instead of
> > "0033 Heisei", as the era changed in 2019. ICU releases have since
> > implem
33 Heisei", as the era changed in 2019. ICU releases have since
implemented this and other corrections; this specific change was
implemented in the batched release of ICU versions on 2019-04-12.
With regards,
Matthias van de Meent
On Mon, 22 Mar 2021 at 21:16, Bernd Helmle wrote:
>
> Hi,
>
> I took a look at this patch.
Thanks!
> Patch applies on current master.
>
> Documentation and adjusted regression tests included.
> Regression tests passes without errors.
>
> The patch changes IMPORT FOREIGN SCHEMA to explicitely
On Fri, 19 Mar 2021 at 19:16, John Naylor wrote:
>
> On Thu, Mar 18, 2021 at 5:30 PM Matthias van de Meent
> wrote:
> >
> > This is slightly more verbose, but I think this clarifies the
> > reasoning why we need this a bit better. Feel free to reject or adap
On Wed, 17 Mar 2021 at 21:52, John Naylor wrote:
>
> On Fri, Mar 12, 2021 at 8:45 AM Matthias van de Meent
> wrote:
> >
> > If this case isn't added, the lower else branch will fail to find
> > fitting pages for len > maxPaddedFsmRequest tuples; potentially
&
On Mon, 15 Mar 2021 at 05:53, Michael Paquier wrote:
>
> On Wed, Mar 10, 2021 at 09:35:10AM +0100, Matthias van de Meent wrote:
> > There are examples in which pg_stat_progress_* -views report
> > inaccurate data. I think it is fairly reasonable to at least validate
> > s
On Thu, 11 Mar 2021 at 16:16, John Naylor wrote:
>
> On Thu, Mar 11, 2021 at 9:46 AM Matthias van de Meent
> wrote:
>
> > Regarding the 2% slack logic, could we change it to use increments of
> > line pointers instead? That makes it more clear what problem this
> &
On Thu, 11 Mar 2021 at 17:31, Robert Haas wrote:
>
> On Tue, Mar 9, 2021 at 3:35 PM Peter Geoghegan wrote:
> > Speaking of line pointer bloat (and "irreversible" bloat), I came
> > across something relevant today. I believe that this recent patch from
> > Mat
I think the same would be true for self-joins on any non-null
> columns covered by a uniqueness constraint.
>
> If this is considered a desirable change, I'd be keen to work on it (with
> some guidance).
There's currently a patch registered in the commitfest that could
FreeSpace > MaxHeapTupleSize)
+ if (len + saveFreeSpace > maxPaddedFsmRequest)
...
- targetFreeSpace = Max(len, MaxHeapTupleSize - (MaxHeapTupleSize * 2 / 100));
+ targetFreeSpace = Max(len, maxPaddedFsmRequest);
...
Other than this, I think this is a good fix.
With regards,
Matthias van de Meent.
On Tue, 9 Mar 2021 at 22:35, Tom Lane wrote:
>
> Matthias van de Meent writes:
> > The only two existing mechanisms that I could find (in the access/heap
> > directory) that possibly could fail on shrunken line pointer arrays;
> > being xlog recovery (I do not have enou
On Tue, 9 Mar 2021 at 06:34, Michael Paquier wrote:
>
> On Mon, Mar 08, 2021 at 05:33:40PM +0100, Matthias van de Meent wrote:
> > Seems reasonable. PFA updated patches. I've renamed the previous 0003
> > to 0002 to keep git-format-patch easy.
>
> Thanks for updating t
on recovery to
determine if that may touch pages that have shrunken line pointer
arrays, or if those situations won't exist due to never using dirtied
pages in recovery) and backwards table scans on non-MVCC snapshots
(which would be fixed in the attached patch).
With regards,
Matthias van d
ace reserved for ItemIds on a
page, keeping valid linepointers intact.
Enjoy,
Matthias van de Meent
[0]
https://www.postgresql.org/message-id/flat/cad21aod0ske11fmw4jd4renawbmcw1wasvnwpjvw3tvqpoq...@mail.gmail.com
[1]
https://www.postgresql.org/message-id/CAEze2Wjf42g
Please don't change this." (Oct. 2000), but I
can't seem to find the documentation / conversations on the
implications that such shrinking would have.
With regards,
Matthias van de Meent.
d, but I'm not sure that would make it into
pg14.
With regards,
Matthias van de Meent.
From 94876abe0ab9c28a6f4b0ac006f356251ca4746c Mon Sep 17 00:00:00 2001
From: Matthias van de Meent
Date: Mon, 8 Mar 2021 16:08:24 +0100
Subject: [PATCH v12 3/3] Adapt COPY progress reporting to report processed
On Thu, 4 Mar 2021 at 17:29, Justin Pryzby wrote:
>
> On Thu, Mar 04, 2021 at 05:19:18PM +0100, Matthias van de Meent wrote:
> >
> > "Backends running [...] report progress to [...] instead" is,
> > a.f.a.i.k., correct English. Adding 'will' would indeed still
ot; is,
a.f.a.i.k., correct English. Adding 'will' would indeed still be
correct, but it would in my opinion also be decremental to the
readability of the section due to the repeated use of the same
template sentence structure. I think that keeping it as-is is just
fine.
With regards,
Matthias van de Meent.
changes
I believe that that was the extent of the not-yet-resolved comments
and suggestions.
With regards,
Matthias van de Meent.
From 7831549452b6d95c3db9060333750256675ff322 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Josef=20=C5=A0im=C3=A1nek?=
Date: Tue, 9 Feb 2021 13:06:45 +0100
Subject: [PATCH v11 3/3]
On Mon, 22 Feb 2021 at 05:49, Bharath Rupireddy
wrote:
>
> On Mon, Feb 22, 2021 at 12:40 AM Matthias van de Meent
> wrote:
> >
> > On Sat, 20 Feb 2021 at 07:09, Bharath Rupireddy
> > wrote:
> > >
> > > For COPY TO the name "source_type" co
Thank you, that's way better! PFA what I believe is a finalized
patchset v9, utilizing io_type terminology instead of io_target.
With regards,
Matthias van de Meent
From 5c0c9658e7c50a2a2d74a738b7bdbfcaa6362e24 Mon Sep 17 00:00:00 2001
From: Matthias van de Meent
Date: Fri, 12 Feb 2021 14:06:44
source*.
Yes, I was also not quite happy with this, but couldn't find a better
one at the point of writing the initial patchset. Would
"io_operations", "io_port", "operates_through" or "through" maybe be
better?
With regards,
Matthias van de Meent
From 40fad
s a pgstat_progress_start_command because CIC / RiC
reindexes all indexes concurrently at the same time (and not grouped
by e.g. table), so we must re-start reporting for each index in each
new phase in which we report data to get the heapId reported correctly
for that index.
With regards,
Matthias van de Meent
de a guide
for implementing such frontend, I see no reason for the postgres
project to put work into such a feature.
With regards,
Matthias van de Meent
[0] I believe this is an optimistic guess, based on the changes that
were (and are yet still) required for the zedstore and/or zheap
tableam, but am happy to be proven wrong.
On Fri, 12 Feb 2021 at 13:40, Bharath Rupireddy
wrote:
>
> On Fri, Feb 12, 2021 at 5:40 PM Matthias van de Meent
> wrote:
> >
> > On Fri, 12 Feb 2021 at 12:23, Matthias van de Meent
> > wrote:
> > >
> > > On Thu, 11 Feb
On Fri, 12 Feb 2021 at 12:23, Matthias van de Meent
wrote:
>
> On Thu, 11 Feb 2021 at 15:44, Bharath Rupireddy
> wrote:
> >
> >
> > On Thu, Feb 11, 2021, 8:08 PM Josef Šimánek wrote:
> >> I have split it since it should be the start of progress reportin
in the view.
With regards,
Matthias van de Meent.
From f7d761f6774753d4914d0dbc80effbb1ab09b58e Mon Sep 17 00:00:00 2001
From: Matthias van de Meent
Date: Mon, 8 Feb 2021 17:36:00 +0100
Subject: [PATCH v4 4/6] Add a command column to the copy progress view
This allows filtering on COPY FROM /
On Wed, 10 Feb 2021 at 07:43, Bharath Rupireddy
wrote:
>
> On Tue, Feb 9, 2021 at 6:02 PM Matthias van de Meent
> wrote:
> > > Also, you can add this to the current commitfest.
> >
> > See https://commitfest.postgresql.org/32/2977/
> >
> > On Tue,
On Tue, 9 Feb 2021 at 08:12, Bharath Rupireddy
wrote:
>
> On Tue, Feb 9, 2021 at 12:06 AM Matthias van de Meent
> wrote:
> > With [0] we got COPY progress reporting. Before the column names of
> > this newly added view are effectively set in stone with the release o
ernal COPY. This would
otherwise be measured, but no knowledge about the type of copy (or its
origin) would be available on the worker's side. I'm not married to
this patch 0005, but I believe it could be useful, and therefore
included it in the patchset.
With regards,
Matthias van de Meent.
On Tue, 19 Jan 2021 at 21:59, Matthias van de Meent
wrote:
>
> On Mon, 18 Jan 2021, 21:25 Álvaro Herrera, wrote:
> >
> > On 2021-Jan-18, Matthias van de Meent wrote:
> >
> > > Example:
> > >
> > > 1.) RI starts
> > > 2.) PHASE 2:
partition during queries, and less suprising behaviour
for LIMIT TO ("table that happens to be a partition").
Regards,
Matthias van de Meent
From f69b961d743b3fdd647b761d6069d8fa9163e2c7 Mon Sep 17 00:00:00 2001
From: Matthias van de Meent
Date: Thu, 21 Jan 2021 13:03:32 +0100
Subject:
On Mon, 18 Jan 2021, 21:25 Álvaro Herrera, wrote:
>
> On 2021-Jan-18, Matthias van de Meent wrote:
>
> > Example:
> >
> > 1.) RI starts
> > 2.) PHASE 2: filling the index:
> > 2.1.) scanning the heap (live tuple is cached)
> > < tuple is deleted
&g
nly
through VACUUM (and optimistic ALL_DEAD detection).
According to my limited knowledge of RI, it requires VACUUM to not run
on the table during the initial index build process (which is
currently guaranteed through the use of a snapshot).
Regards,
Matthias van de Meent
On Thu, 7 Jan 2021 at 23:00, Josef Šimánek wrote:
>
> čt 7. 1. 2021 v 22:37 odesílatel Tomas Vondra
> napsal:
> >
> > I'm not particularly attached to the "lines" naming, it just seemed OK
> > to me. So if there's consensus to rename this somehow, I'm OK with it.
>
> The problem I do see here is
on user of COPY is the pg_dump tool, and that uses binary
format by default (iirc).
Additionally, all comments surrounding the *LINES_PROCESSED updates
only mention 'tuples', so I'd like to strongly suggest (a variant of)
attached patch 0002 to keep the vocabulary consistent
disambiguates the meaning in case of e.g. COPY FROM (format CSV), as
multiline CSV fields do exist, and we're not necessarily counting lines
from or to a file.
With regards,
Matthias van de Meent
On Mon, 7 Dec 2020 at 11:09, Peter Eisentraut
wrote:
>
> get_constraint_index() does its work by going through pg_depend. It was
> added before pg_constraint.conindid was added, and some callers are
> still not changed. Are there reasons for that? Probably not. The
> attached patch changes
ble scan finishes.
>
PFA a patch with updated message and comment. I've reworded the
messages to specifically mention empty pages and the need for setting
heap_blks_scanned = total_heap_blks explicitly.
Feel free to update the specifics, other than that I think this is a
complete fix for
On Wed, 25 Nov 2020 at 10:35, Fujii Masao wrote:
>
> On 2020/11/25 0:25, Matthias van de Meent wrote:
> >
> > I noticed that with my proposed patch it is still possible to go to
> > the next phase while heap_blks_scanned != heap_blks_total. This can
> > happen whe
On Tue, 24 Nov 2020 at 15:05, Fujii Masao wrote:
>
> On 2020/11/21 2:32, Matthias van de Meent wrote:
> > Hi,
> >
> > The pg_stat_progress_cluster view can report incorrect
> > heap_blks_scanned values when synchronize_seqscans is enabled, because
> >
van de Meent
From 12f7617f4999b7bf85cc2c9ef4c3b96aac3b26e8 Mon Sep 17 00:00:00 2001
From: Matthias van de Meent
Date: Fri, 20 Nov 2020 16:23:59 +0100
Subject: [PATCH v1] Fix CLUSTER progress reporting of number of blocks
scanned.
The heapScan need not start at block 0, so heapScan->rs_cb
On Thu, 5 Nov 2020 at 17:01, Konstantin Knizhnik
wrote:
>
> Sorry, I do not understand your point.
> This view reports network traffic from server's side.
> But client's traffic information is "mirror" of this statistic:
> server_tx=client_rx and visa versa.
>
> Yes, first few bytes exchanged by
On Mon, 2 Nov 2020 at 20:20, Konstantin Knizhnik
wrote:
>
> On 02.11.2020 19:53, Matthias van de Meent wrote:
> > This is the result of network traffic of two backends one with enabled
> >> compression and another with disable compression
> >> after execution of &q
On Mon, 2 Nov 2020 at 15:03, Konstantin Knizhnik
wrote:
>
> It seems to be very important to be able to measure network traffic
> between client and server, especially in case of using compression.
> Althought there are a lot of toll for monitoring network traffix for
> Linux and other OSes, I
On Fri, 25 Sep 2020 at 08:44, Michael Paquier wrote:
>
> On Thu, Sep 24, 2020 at 09:19:18PM +0200, Matthias van de Meent wrote:
> > While working on a PG12-instance I noticed that the progress reporting of
> > concurrent index creation for non-index relations fails to up
which properly sets these values at the appropriate places.
Any thoughts?
Matthias van de Meent
From f41da096b1f36118917fe345e2a6fc89530a40c9 Mon Sep 17 00:00:00 2001
From: Matthias van de Meent
Date: Thu, 24 Sep 2020 20:41:10 +0200
Subject: [PATCH] Report the active index for reindex table
uplication.
Thanks,
Matthias van de Meent
[0] https://archive.org/stream/symmetricconcurr00lani
only the named functions.
Finally, this could be a great start on prefix truncation for btree
indexes, though that is _not_ the goal of this patch. This patch skips, but
does not truncate, the common prefix.
Kind regards,
Matthias van de Meent
P.S. One more thing I noticed in benchmar
501 - 564 of 564 matches
Mail list logo
