On 1/27/25 20:56, Ants Aasma wrote:
I'll set the patch "ready for committer".
Thanks!
I personally would still like to know how fragmentation slows down performance.
Probable reason is that scanning an unfragmented index results in
sequential I/O patterns that the kernel read-ahead mechan
On Mon, 27 Jan 2025 at 11:21, Laurenz Albe wrote:
> > He reported to our team, that he did a test with two indexes on the same
> > data. They had the same density but one had no fragmentation while the
> > other had 100%. He got an execution time of ~90ms (0 frag) vs ~340ms
> > 100% frag).
> >
> >
On Mon, 2025-01-27 at 10:13 +0100, Benoit Lobréau wrote:
> On 1/25/25 7:07 PM, Laurenz Albe wrote:
> > Looks good to me. I have one question left: the explanation for the
> > performance
> > penalty of a high leaf fragmentation sounds like it would only be relevant
> > for
> > disks where sequen
On 1/25/25 7:07 PM, Laurenz Albe wrote:
Looks good to me. I have one question left: the explanation for the performance
penalty of a high leaf fragmentation sounds like it would only be relevant for
disks where sequential reads are faster. If that is correct, perhaps it would
be
worth mentioni
On Fri, 2025-01-24 at 15:41 +0100, Frédéric Yhuel wrote:
> v4 attached
Looks good to me. I have one question left: the explanation for the performance
penalty of a high leaf fragmentation sounds like it would only be relevant for
disks where sequential reads are faster. If that is correct, perha
the typo). v4 attached
Thanks! :-)From d78c787de917068c07dea96d247795fbe256df7d Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 23 Jan 2025 14:44:29 +0100
Subject: [PATCH v4] doc: explain pgstatindex fragmentation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It was quite hard
On Fri, 2025-01-24 at 13:34 +, Bertrand Drouvot wrote:
> + Since indexes have a default fillfactor of 90, this should be around 0.9 for
> + newly built indexes
>
> I think 0.9 should be replaced by 90 (that's the actual kind of output we'd
> get).
>
> But having said that, I'm not sure we sh
Hi,
On Fri, Jan 24, 2025 at 12:34:08PM +0100, Frédéric Yhuel wrote:
> I don't know if you noticed Laurenz's suggestion, because he forgot to CC
> you, but I like it very much. I think we should mention the default
> fillfactor (90 for indexes).
Thanks for mentioning Laurenz's suggestion!
=== 1
Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 23 Jan 2025 14:44:29 +0100
Subject: [PATCH v3] doc: explain pgstatindex fragmentation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It was quite hard to guess what leaf_fragmentation meant without
Hi Frédéric,
On Thu, Jan 23, 2025 at 10:00:27AM +0100, Frédéric Yhuel wrote:
> On 1/22/25 12:34, Bertrand Drouvot wrote:
> > I'm not sure it's good to describe something as the inverse of "something
> > else". See my proposal below.
> >
>
> Yeah... bloat is a more familiar concept, so I wanted t
ate: Thu, 23 Jan 2025 14:44:29 +0100
Subject: [PATCH v2] doc: explain pgstatindex fragmentation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It was quite hard to guess what leaf_fragmentation meant without looking
at pgstattuple's code. This
On 1/22/25 12:34, Bertrand Drouvot wrote:
Hi,
On Tue, Nov 05, 2024 at 06:36:47PM +0100, Frédéric Yhuel wrote:
Hi, I thought it would be nice to give the user a better idea of what
avg_leaf_density and leaf_fragmentation mean.
Patch attached. What do you think?
Yeah, I think that can not h
Hi,
On Tue, Nov 05, 2024 at 06:36:47PM +0100, Frédéric Yhuel wrote:
> Hi, I thought it would be nice to give the user a better idea of what
> avg_leaf_density and leaf_fragmentation mean.
>
> Patch attached. What do you think?
Yeah, I think that can not hurt to give more details, thanks for the
On 1/22/25 10:24, Benoit Lobréau wrote:
Here is an updated patch to save you some time.
Thanks ! it does seems better that way.
Here is an updated patch to save you some time.
--
Benoit Lobréau
Consultant
http://dalibo.com
From 5d89ca0a36e98d1e5be858166a8394c09e0fa129 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Yhuel?=
Date: Tue, 5 Nov 2024 17:59:44 +0100
Subject: [PATCH] doc: explain pgstatindex
Hi,
I like the clarification but I think that:
A higher leaf_fragmentation indicates that the
physical order of the index leaf
pages increasingly deviates from their logical order.
Would be cleaner than:
The higher leaf_fragmentation is, the less the
physical order
of the index leaf pages c
:44 +0100
Subject: [PATCH] doc: explain pgstatindex fragmentation
It was quite hard to guess what leaf_fragmentation meant without looking
at pgstattuple's code. This patch aims to give to the user a better
idea of what it means.
---
doc/src/sgml/pgstattuple.sgml | 8
1 file chang
17 matches
Mail list logo
