Hi,
On 2024-04-08 16:18:21 +1200, David Rowley wrote:
> On Mon, 8 Apr 2024 at 16:08, Andres Freund wrote:
> > I think visible would be ok, the serialization checks are IMO about
> > visibility too. But if you'd prefer I'd also be ok with something like
> > page_collect_tuples()?
>
> That's ok fo
On Mon, 8 Apr 2024 at 16:08, Andres Freund wrote:
>
> On 2024-04-08 15:43:12 +1200, David Rowley wrote:
> > I understand wanting to avoid the long name. I'd rather stay clear of
> > "visible", but don't feel as strongly about this as it's static.
>
> I think visible would be ok, the serialization
Hi,
On 2024-04-08 15:43:12 +1200, David Rowley wrote:
> On Mon, 8 Apr 2024 at 15:13, Andres Freund wrote:
> > Off-list Melanie suggested heap_page_collect_visible_tuples(). Given the
> > separate callsites (making long names annoying) and the fact that it's
> > really
> > specific to one caller,
On Mon, 8 Apr 2024 at 15:13, Andres Freund wrote:
> I kinda don't like heap_prepare_pagescan(), but heapgetpage() is worse. And I
> don't have a great alternative suggestion.
It came around from having nothing better. I was keen not to have the
name indicate it was only for checking visibility a
Hi,
On 2024-04-08 14:43:21 +1200, David Rowley wrote:
> On Sun, 7 Apr 2024 at 19:30, Andres Freund wrote:
> > Good call. Added and pushed.
>
> I understand you're already aware of the reference in the comment to
> heapgetpage(), which no longer exists as of 44086b097.
Yea, https://postgr.es/m/2
On Sun, 7 Apr 2024 at 19:30, Andres Freund wrote:
> Good call. Added and pushed.
I understand you're already aware of the reference in the comment to
heapgetpage(), which no longer exists as of 44086b097.
Melanie and I had discussed the heap_prepare_pagescan() name while I
was reviewing that rec
Hi,
On 2024-04-07 12:07:22 +0700, John Naylor wrote:
> Just in time ;-) The commit message should also have "reviewed by
> Zhang Mingli" and "tested by Quan Zongliang", who shared results in a
> thread for a withrawn CF entry with a similar idea but covering fewer
> cases:
Good call. Added and pu
On Sun, Apr 7, 2024 at 11:49 AM Andres Freund wrote:
>
> Hi,
>
> On 2024-01-22 13:01:31 +0700, John Naylor wrote:
> > On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
> > > And 397->320ms
> > > for something as core as this, is imo worth considering on its own.
> >
> > Hi Andres, this interes
Hi,
On 2024-01-22 13:01:31 +0700, John Naylor wrote:
> On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
> > And 397->320ms
> > for something as core as this, is imo worth considering on its own.
>
> Hi Andres, this interesting work seems to have fallen off the radar --
> are you still planni
On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
> And 397->320ms
> for something as core as this, is imo worth considering on its own.
Hi Andres, this interesting work seems to have fallen off the radar --
are you still planning to move forward with this for v17?
On Fri, Sep 1, 2023 at 1:08 PM tender wang wrote:
>
> This thread [1] also Improving the heapgetpage function, and looks like
this thread.
>
> [1]
https://www.postgresql.org/message-id/a9f40066-3d25-a240-4229-ec2fbe94e7a5%40yeah.net
Please don't top-post.
For the archives: That CF entry has been
On Wed, Sep 6, 2023 at 1:38 AM Andres Freund wrote:
> > > I think that makes it less likely that the compiler actually
generates a
> > > constant-folded version for each of the branches. Perhaps worth some
> > > experimentation.
> >
> > Combining this way doesn't do so for me.
>
> Are you saying
Hi,
On 2023-09-05 14:42:57 +0700, John Naylor wrote:
> On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
>
> > FWIW, there's more we can do, with some hacky changes I got the time down
> to
> > 273.261, but the tradeoffs start to be a bit more complicated. And
> 397->320ms
> > for something as
On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
> FWIW, there's more we can do, with some hacky changes I got the time down
to
> 273.261, but the tradeoffs start to be a bit more complicated. And
397->320ms
> for something as core as this, is imo worth considering on its own.
Nice!
> On 20
This thread [1] also Improving the heapgetpage function, and looks like
this thread.
[1]
https://www.postgresql.org/message-id/a9f40066-3d25-a240-4229-ec2fbe94e7a5%40yeah.net
Muhammad Malik 于2023年9月1日周五 04:04写道：
> Hi,
>
> Is there a plan to merge this patch in PG16?
>
> Thanks,
> Muhammad
>
> -
Hi,
Is there a plan to merge this patch in PG16?
Thanks,
Muhammad
From: Andres Freund
Sent: Saturday, July 15, 2023 6:56 PM
To: pgsql-hack...@postgresql.org
Cc: Thomas Munro
Subject: Improve heapgetpage() performance, overhead from serializable
Hi,
Several l
Hi,
On 2023-07-17 09:55:07 +0800, Zhang Mingli wrote:
> LGTM and I have a fool question:
>
> if (likely(all_visible))
> {
> if (likely(!check_serializable))
> scan->rs_ntuples = heapgetpage_collect(scan, snapshot,
> page, buffer,
>
Hi,
Regards,
Zhang Mingli
On Jul 16, 2023 at 09:57 +0800, Andres Freund , wrote:
> Hi,
>
> Several loops which are important for query performance, like heapgetpage()'s
> loop over all tuples, have to call functions like
> HeapCheckForSerializableConflictOut() and PredicateLockTID() in every
> ite
18 matches
Mail list logo
