| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | vignesh C <vignesh21(at)gmail(dot)com> |
| Cc: | Kirill Reshke <reshkekirill(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Re: in BeginCopyTo make materialized view using COPY TO instead of COPY (query). |
| Date: | 2025-04-01 14:27:24 |
| Message-ID: | CAKFQuwZQFhkOR4VAZoH_Hd0OhCJx-mHW4dRFk1R7phjemvjbbg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 1, 2025 at 6:52 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> 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?
>
>
No, for the same reason the caveat about WITH NO DATA need not be mentioned
either. These are the inherent properties/trade-offs of using a
materialized view versus a normal view. They are discussed when talking
about the creation and usage of materialized views specifically. Features
that interact with materialized views consistent with these two documented
properties do not need to point out that fact. i.e., the existing
non-documenting of those two points in SELECT is appropriate, and should be
emulated in COPY. The output doesn't change if you write "copy table"
instead of "copy (select * from table)" so nothing needs to be pointed out.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2025-04-01 14:37:50 | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
| Previous Message | Alena Rybakina | 2025-04-01 14:23:02 | Re: Replace IN VALUES with ANY in WHERE clauses during optimization |