| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: BTScanOpaqueData size slows down tests |
| Date: | 2025-04-02 16:09:50 |
| Message-ID: | CAH2-Wz=YA+-94g3XAr3EZrc8b7vb1Nk6k9G-Aa0cDP_H5LCzVg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 2, 2025 at 12:08 PM Andres Freund <andres(at)anarazel(dot)de> 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 necessarily have to return all of the TIDs
> > from such a page, if it has to return any.
>
> I'm not sure what you're arguing for/against here? Obviously we need to handle
> that case. I doubt that the overhead of once-per-scan allocation of a
> MaxTIDsPerBTreePage * sizeof(BTScanPosItem) array once per scan matters when
> that many tuples are returned.
I'm not arguing for or against anything. I'm just giving context.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-04-02 16:10:43 | Re: BTScanOpaqueData size slows down tests |
| Previous Message | Andres Freund | 2025-04-02 16:08:35 | Re: BTScanOpaqueData size slows down tests |