Re: in BeginCopyTo make materialized view using COPY TO instead of COPY (query).
Kirill Reshke <reshkekirill@gmail.com>
From: Kirill Reshke <reshkekirill@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: jian he <jian.universality@gmail.com>,
Fujii Masao <masao.fujii@oss.nttdata.com>, Andrew Dunstan <andrew@dunslane.net>,
"David G. Johnston" <david.g.johnston@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>
Date: 2025-04-01T14:14:31Z
Lists: pgsql-hackers
On Tue, 1 Apr 2025 at 15:52, vignesh C <vignesh21@gmail.com> wrote: > > On Tue, 1 Apr 2025 at 15:49, Kirill Reshke <reshkekirill@gmail.com> wrote: > > > > On Tue, 1 Apr 2025, 11:45 vignesh C, <vignesh21@gmail.com> wrote: > >> > >> > >> One thing I noticed was that if the materialized view is not refreshed > >> user will get stale data > >> > >> Should we document this? > > > > Does this patch alter thus behaviour? User will get stale data even on HEAD, why should we take a care within this thread? > > We are not changing the existing behavior. However, since copying data > from large tables can take a significant amount of time, would it be > helpful to add a cautionary note advising users to refresh the > materialized view before running copy command to avoid stale data? > This could prevent users from realizing the issue only after running > the copy operation, which would then require them to run it again. Yes, agree, +1 on that. > If > you think this is already obvious, then the note may not be necessary. I don't think this is already obvious, but my objection is that we should maybe discuss this as a separate issue (in a separate patch). Looks like fixing this together with code commit is too much at once. I prefer a one-commit-for-one-purpose style. > Regards, > Vignesh -- Best regards, Kirill Reshke
Commits
-
Allow "COPY table TO" command to copy rows from materialized views.
- 534874fac0b3 18.0 landed