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
nks,
> 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,
>
> Seve
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
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
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
iteration.
When serializable is not in use, all those functions do is to to return. But
being s
19 matches
Mail list logo
