On Tue, 1 Apr 2025 at 15:49, Kirill Reshke wrote:
>
> On Tue, 1 Apr 2025, 11:45 vignesh C, 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 stal
On Saturday, March 29, 2025, Kirill Reshke wrote:
> On Sat, 29 Mar 2025 at 09:47, jian he wrote:
> >
> > will use {table_beginscan, table_scan_getnextslot, table_endscan}
> > to output the data.
> > but views don't have storage, table_beginscan mechanism won't work.
> >
> > so i don't think this
On Sat, Mar 29, 2025 at 11:56 AM Andrew Dunstan wrote:
> I don't believe that the premise supports the conclusion.
>
>
> Regardless, I do support this patch and probably any similar ones proposed
in the future. Do you have an opinion on that?
David J.
On Wed, Apr 2, 2025 at 11:20 PM Fujii Masao wrote:
> >
> > if (!RelationIsPopulated(rel))
> > ereport(ERROR,
> > errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> > errmsg("cannot copy from unpopulated
> > materialized view \"
On 2025/04/01 12:12, jian he wrote:
On Mon, Mar 31, 2025 at 11:27 PM Fujii Masao
wrote:
Regarding the patch, here are some review comments:
+ errmsg("cannot copy from
materialized view when the materialized view is not populated"),
How about
On 2025-03-29 Sa 10:40 AM, David G. Johnston wrote:
On Saturday, March 29, 2025, Kirill Reshke wrote:
On Sat, 29 Mar 2025 at 09:47, jian he
wrote:
>
> will use {table_beginscan, table_scan_getnextslot, table_endscan}
> to output the data.
> but views don't have storage
On 2025/04/03 20:46, Fujii Masao wrote:
Thanks for updating the patch! I made some minor cosmetic changes
and updated the commit log. The revised patch is attached.
Unless there are any objections, I'll proceed with committing it.
I've pushed the patch. Thanks!
As a follow-up, it might be
On 2025/04/03 17:53, jian he wrote:
On Wed, Apr 2, 2025 at 11:20 PM Fujii Masao wrote:
if (!RelationIsPopulated(rel))
ereport(ERROR,
errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot copy from unpopulate
On Tue, Apr 1, 2025 at 6:52 AM vignesh C 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 cop
On Tue, 1 Apr 2025 at 15:52, vignesh C wrote:
>
> On Tue, 1 Apr 2025 at 15:49, Kirill Reshke wrote:
> >
> > On Tue, 1 Apr 2025, 11:45 vignesh C, wrote:
> >>
> >>
> >> One thing I noticed was that if the materialized view is not refreshed
> >> user will get stale data
> >>
> >> Should we document
On Tue, 1 Apr 2025 at 08:43, jian he wrote:
>
> On Mon, Mar 31, 2025 at 11:27 PM Fujii Masao
> wrote:
> >
> > Regarding the patch, here are some review comments:
> >
> > + errmsg("cannot copy from
> > materialized view when the materialized view is n
On Tue, 1 Apr 2025, 11:45 vignesh C, 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 thr
On Mon, Mar 31, 2025 at 8:13 PM jian he wrote:
> On Mon, Mar 31, 2025 at 11:27 PM Fujii Masao
>
> >
> > The copy.sgml documentation should clarify that COPY TO can
> > be used with a materialized view only if it is populated.
> >
> "COPY TO can be used only with plain tables, not views, and does
On Mon, Mar 31, 2025 at 11:27 PM Fujii Masao
wrote:
>
> Regarding the patch, here are some review comments:
>
> + errmsg("cannot copy from
> materialized view when the materialized view is not populated"),
>
> How about including the object name for c
On 2025/03/30 5:01, Andrew Dunstan wrote:
On 2025-03-29 Sa 2:58 PM, David G. Johnston wrote:
On Sat, Mar 29, 2025 at 11:56 AM Andrew Dunstan wrote:
I don't believe that the premise supports the conclusion.
Regardless, I do support this patch and probably any similar ones proposed in
On 2025-03-29 Sa 2:58 PM, David G. Johnston wrote:
On Sat, Mar 29, 2025 at 11:56 AM Andrew Dunstan
wrote:
I don't believe that the premise supports the conclusion.
Regardless, I do support this patch and probably any similar ones
proposed in the future. Do you have an opinion on that?
On Sat, Mar 29, 2025 at 12:27 PM Kirill Reshke
wrote:
> On Sat, 29 Mar 2025 at 19:59, David G. Johnston
> wrote:
> > Regardless, I do support this patch and probably any similar ones
> proposed in the future. Do you have an opinion on that?
> >
>
> I do also support what this patch aims to do,
On Sat, 29 Mar 2025 at 19:59, David G. Johnston
wrote:
> Regardless, I do support this patch and probably any similar ones proposed in
> the future. Do you have an opinion on that?
>
> David J.
>
I do also support what this patch aims to do, how do you like v1?
--
Best regards,
Kirill Reshke
On 2025-03-29 Sa 12:17 PM, David G. Johnston wrote:
On Sat, Mar 29, 2025 at 9:06 AM Andrew Dunstan
wrote:
On 2025-03-29 Sa 10:40 AM, David G. Johnston wrote:
On Saturday, March 29, 2025, Kirill Reshke
wrote:
On Sat, 29 Mar 2025 at 09:47, jian he
wrote:
On Sat, Mar 29, 2025 at 9:06 AM Andrew Dunstan wrote:
>
> On 2025-03-29 Sa 10:40 AM, David G. Johnston wrote:
>
> On Saturday, March 29, 2025, Kirill Reshke wrote:
>
>> On Sat, 29 Mar 2025 at 09:47, jian he
>> wrote:
>> >
>> > will use {table_beginscan, table_scan_getnextslot, table_endscan}
>>
On Sat, 29 Mar 2025 at 09:47, jian he wrote:
>
> will use {table_beginscan, table_scan_getnextslot, table_endscan}
> to output the data.
> but views don't have storage, table_beginscan mechanism won't work.
>
> so i don't think this is possible for view.
Well... So you are saying that let us have
On Thu, Mar 27, 2025 at 3:04 AM Kirill Reshke wrote:
> >
> > hi.
> > patch attached.
> > also cc to Tom,
> > since at that time, you are against the idea of ``COPY matview TO``.
>
> Hi! With this patch it is possible to COPY matview TO, but not regular
> view, which is surprising. Let's fix that?
On Tue, 28 Jan 2025 at 07:49, jian he wrote:
>
> On Mon, Jan 6, 2025 at 5:34 PM jian he wrote:
> >
> > hi.
> >
> > about this issue,
> > last email in 2012 (https://postgr.es/m/8967.1353167...@sss.pgh.pa.us)
> > """
> > Even if it happens to be trivial in the current patch, it's an added
> > func
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi,
Tested the latest patch that allows direct `COPY` operations on Materiali
On Mon, Jan 6, 2025 at 5:34 PM jian he wrote:
>
> hi.
>
> about this issue,
> last email in 2012 (https://postgr.es/m/8967.1353167...@sss.pgh.pa.us)
> """
> Even if it happens to be trivial in the current patch, it's an added
> functional requirement that we might later regret having cavalierly
>
hi.
about this issue,
last email in 2012 (https://postgr.es/m/8967.1353167...@sss.pgh.pa.us)
"""
Even if it happens to be trivial in the current patch, it's an added
functional requirement that we might later regret having cavalierly
signed up for. And, as noted upthread, relations that support on
On Fri, Dec 20, 2024 at 8:02 AM Michael Paquier wrote:
>
> On Thu, Dec 19, 2024 at 02:28:21PM +0800, jian he wrote:
> > Since materialized views have physical storage,
> >
> > we can make materialized views also using COPY table_name, instead of
> > COPY(query).
> >
> > Some simple tests show arou
On Thu, Dec 19, 2024 at 02:28:21PM +0800, jian he wrote:
> Since materialized views have physical storage,
>
> we can make materialized views also using COPY table_name, instead of
> COPY(query).
>
> Some simple tests show around %3.7 or 4.3% speed up.
This restriction comes from 3bf3ab8c5636 as
28 matches
Mail list logo
