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.
11 matches
Mail list logo
