| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Trying out read streams in pgvector (an extension) |
| Date: | 2025-11-11 22:52:17 |
| Message-ID: | CAAKRu_ZVxzwRRbxedgb_LtkFaGf78XAbTO9uExvadV2DzaE=Jg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 11, 2025 at 4:22 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> But for now, to fix pgvector's woes, I wonder if it might make sense
> to call this a bug in v18, and back-patch the tiniest possible change.
> Something like what I posted[2] in this thread almost two years ago.
> I don't think it really affects any core code: we use
> read_stream_reset() only in very minimal ways there (I could
> elaborate), and it's quite arguable that the existing policy is wrong
> for them too, but we'd need to confirm that and perhaps think about
> other extensions that might be using it.
If we are worried about regressing other extensions using
read_stream_reset(), we could make the read stream reset which
preserves the distance a different function in backbranches.
- Melanie
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rohit Prasad | 2025-11-11 23:17:05 | Re: Include extension path on pg_available_extensions |
| Previous Message | Manni Wood | 2025-11-11 22:23:20 | Re: Speed up COPY FROM text/CSV parsing using SIMD |