On Thu, 3 Apr 2025 at 04:21, Andres Freund wrote:
> I was mildly
> surprised to see how expensive the new compact attribute checks are.
Is this a fairly deform-heavy workload? FWIW, before adding that
Assert, I did test to see if there was any measurable impact on the
time it took to run all the
Hi,
On 2025-04-02 11:36:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Looking at the size of BTScanOpaqueData I am less surprised:
> > /* size: 27352, cachelines: 428, members: 17 */
> > allocating, zeroing and freeing 28kB of memory for every syscache miss, yea,
> > that's gonna
On Wed, Apr 2, 2025 at 12:10 PM Tom Lane wrote:
> I could get behind the idea of just having enough space in
> BTScanOpaqueData for about ten items, and dynamically allocating
> a MaxTIDsPerBTreePage-sized array only if we overrun that.
> And not allocate any space for mark/restore unless a mark i
Andres Freund writes:
> I'm a bit confused by the "MUST BE LAST" comment:
> BTScanPosItem items[MaxTIDsPerBTreePage]; /* MUST BE LAST */
Yeah, me too. It looks like it might've been intended to allow
the items[] array to be only partially allocated. But as Peter
says, we don't do th
On Wed, Apr 2, 2025 at 12:08 PM Andres Freund wrote:
> > It isn't at all rare for the scan to have to return about 1350 TIDs
> > from a page, though. Any low cardinality index will tend to have
> > almost that many TIDs to return on any page that only stores
> > duplicates. And scan will necessari
Hi,
On 2025-04-03 11:26:08 +1300, David Rowley wrote:
> On Thu, 3 Apr 2025 at 04:21, Andres Freund wrote:
> > I was mildly
> > surprised to see how expensive the new compact attribute checks are.
>
> Is this a fairly deform-heavy workload?
It was our regression tests, although I was playing aro
On Wed, Apr 2, 2025 at 11:57 AM Andres Freund wrote:
> I'd assume it's extremely rare for there to be this many items on a page. I'd
> guess that something like storing having BTScanPosData->items point to an
> in-line 4-16 BTScanPosItem items_inline[N] and dynamically allocate a
> full-length BTS
On Wed, Apr 2, 2025 at 12:43 PM Álvaro Herrera wrote:
> I'm just saying that this is the reason to have the field be last in the
> struct.
Right. And I'm just saying that I don't think that it would take very
much effort to change it. That aspect isn't performance critical.
--
Peter Geoghegan
On 4/2/25 17:45, Peter Geoghegan wrote:
> On Wed, Apr 2, 2025 at 11:36 AM Tom Lane wrote:
>> Ouch! I had no idea it had gotten that big. Yeah, we ought to
>> do something about that.
>
> Tomas Vondra talked about this recently, in the context of his work on
> prefetching.
>
I might have menti
On Wed, Apr 2, 2025 at 11:36 AM Tom Lane wrote:
> Ouch! I had no idea it had gotten that big. Yeah, we ought to
> do something about that.
Tomas Vondra talked about this recently, in the context of his work on
prefetching.
> > And/or perhaps we could could allocate BTScanOpaqueData.markPos as
On 2025-Apr-02, Peter Geoghegan wrote:
> On Wed, Apr 2, 2025 at 12:31 PM Álvaro Herrera
> wrote:
> > The mentioned commit (09cb5c0e7d6f) shows that we do partial memcpys, e.g.
> >
> > + memcpy(&so->markPos, &so->currPos,
> > + offsetof(BTScanPosData, items[1]) +
> > +
On Wed, Apr 2, 2025 at 12:31 PM Álvaro Herrera wrote:
> The mentioned commit (09cb5c0e7d6f) shows that we do partial memcpys, e.g.
>
> + memcpy(&so->markPos, &so->currPos,
> + offsetof(BTScanPosData, items[1]) +
> + so->currPos.lastItem * sizeof(BTScanPosItem));
>
>
On 2025-Apr-02, Tom Lane wrote:
> Andres Freund writes:
> > I'm a bit confused by the "MUST BE LAST" comment:
> > BTScanPosItem items[MaxTIDsPerBTreePage]; /* MUST BE LAST */
>
> Yeah, me too. It looks like it might've been intended to allow
> the items[] array to be only partially al
Peter Geoghegan writes:
> It isn't at all rare for the scan to have to return about 1350 TIDs
> from a page, though. Any low cardinality index will tend to have
> almost that many TIDs to return on any page that only stores
> duplicates. And scan will necessarily have to return all of the TIDs
> f
Hi,
On 2025-04-02 12:01:57 -0400, Peter Geoghegan wrote:
> On Wed, Apr 2, 2025 at 11:57 AM Andres Freund wrote:
> > I'd assume it's extremely rare for there to be this many items on a page.
> > I'd
> > guess that something like storing having BTScanPosData->items point to an
> > in-line 4-16 BTS
Andres Freund writes:
> Looking at the size of BTScanOpaqueData I am less surprised:
> /* size: 27352, cachelines: 428, members: 17 */
> allocating, zeroing and freeing 28kB of memory for every syscache miss, yea,
> that's gonna hurt.
Ouch! I had no idea it had gotten that big. Yeah, we
16 matches
Mail list logo
