On Wed, Mar 22, 2023 at 10:38 PM Corey Huinker wrote:
> That's probably a good move, especially if we start tallying updates that use
> TOAST.
Okay, pushed.
Thanks
--
Peter Geoghegan
>
>
> * No more dedicated struct to carry around the type of an update.
>
> We just use two boolean arguments to the pgstats function instead. The
> struct didn't seem to be adding much, and it was distracting to track
> the information this way within heap_update().
>
That's probably a good move,
On Wed, Mar 22, 2023 at 05:14:08PM -0700, Peter Geoghegan wrote:
> * Small adjustments to the documentation.
>
> Nearby related items were tweaked slightly to make everything fit
> together a bit better. For example, the description of n_tup_hot_upd
> is revised to make it obvious that n_tup_hot_u
On Fri, Mar 17, 2023 at 3:22 PM Peter Geoghegan wrote:
> I think that this is pretty close to being committable already.
Attached revision has some small tweaks by me. Going to commit this
revised version tomorrow morning.
Changes:
* No more dedicated struct to carry around the type of an updat
On Fri, Jan 27, 2023 at 3:23 PM Corey Huinker wrote:
> This patch adds the n_tup_newpage_upd to all the table stat views.
I think that this is pretty close to being committable already.
I'll move on that early next week, barring any objections.
--
Peter Geoghegan
Hi,
On 2023-01-30 13:40:15 -0500, Corey Huinker wrote:
> I must be missing something, I only see the check for running out of space,
> not the check for exhausting line pointers. I agree dividing them would be
> interesting.
See PageGetHeapFreeSpace(), particularly the header comment and the
MaxH
On Fri, Jan 27, 2023 at 6:55 PM Andres Freund wrote:
> Hi,
>
> On 2023-01-27 18:23:39 -0500, Corey Huinker wrote:
> > This patch adds the n_tup_newpage_upd to all the table stat views.
> >
> > Just as we currently track HOT updates, it should be beneficial to track
> > updates where the new tuple
On Fri, Jan 27, 2023 at 6:44 PM Andres Freund wrote:
> I don't think that'd make it particularly easy to figure out how often
> out-of-space causes non-HOT updates to go out of page, and how often it causes
> potential HOT updates to go out of page. If you just have a single index,
> it's not too
Hi,
On 2023-01-27 17:59:32 -0800, Peter Geoghegan wrote:
> > I think this might cause some trouble for existing monitoring setups after
> > an
> > upgrade. Suddenly the number of updates will appear way lower than
> > before... And if we end up eventually distinguishing between different
> > rea
On Fri, Jan 27, 2023 at 3:55 PM Andres Freund wrote:
> I wonder if it's quite detailed enough - we can be forced to do out-of-page
> updates because we actually are out of space, or because we reach the max
> number of line pointers we allow in a page. HOT pruning can't remove dead line
> pointers
Hi,
On 2023-01-27 18:23:39 -0500, Corey Huinker wrote:
> This patch adds the n_tup_newpage_upd to all the table stat views.
>
> Just as we currently track HOT updates, it should be beneficial to track
> updates where the new tuple cannot fit on the existing page and must go to
> a different one.
This patch adds the n_tup_newpage_upd to all the table stat views.
Just as we currently track HOT updates, it should be beneficial to track
updates where the new tuple cannot fit on the existing page and must go to
a different one.
Hopefully this can give users some insight as to whether their cu
12 matches
Mail list logo
