On Thu, 11 Sept 2025 at 19:27, Álvaro Herrera wrote:
>
> On 2025-Sep-11, Kirill Reshke wrote:
>
> > I think we can remove "support" for ALTER DATABASE RESET TABLESPACE.
>
> What about ALTER USER RESET TABLESPACE?
>
> --
> Álvaro Herrer
```
Notice we have "(full page image)" from gindesc and "FPW" from generic
waldump code
I suggest removing this custom FPW support.
--
Best regards,
Kirill Reshke
v1-0001-Remove-custom-full-page-write-decribption-from-GI.patch
Description: Binary data
connections (
max_connections ~ 1e4) for zero benefit.
--
Best regards,
Kirill Reshke
out support of something
like this. [0]
This test case looks like just an oversight of 0844b3968985
I think we can remove "support" for ALTER DATABASE RESET TABLESPACE.
LGTM
[0] https://www.postgresql.org/docs/current/sql-alterdatabase.html
--
Best regards,
Kirill Reshke
is area, we may as
> well close the gap in the output produced.
Sure
PFA v2.
--
Best regards,
Kirill Reshke
v2-0001-Display-more-fields-of-xl_hash-wal-records.patch
Description: Binary data
-source pg-related project).
PFA fixing issue.
--
Best regards,
Kirill Reshke
v1-0001-Display-is_prev_bucket_same_wrt-of-xl_hash_squeez.patch
Description: Binary data
ach other.
Ahh... sorry for the noise, this part is wrong.
PFA v2
--
Best regards,
Kirill Reshke
v2-0001-Fix-comments-in-xlog.h.patch
Description: Binary data
ttps://git.postgresql.org/cgit/postgresql.git/tree/src/backend/access/hash/hash_xlog.c?id=567d27e8e2b752743626eb259ba75ecdc936eaf3#n830
--
Best regards,
Kirill Reshke
v1-0001-Fix-comments-in-xlog.h.patch
Description: Binary data
On Wed, 3 Sept 2025 at 04:11, Melanie Plageman
wrote:
>
> On Tue, Sep 2, 2025 at 5:52 PM Melanie Plageman
> wrote:
> >
> > On Thu, Aug 28, 2025 at 5:12 AM Kirill Reshke
> > wrote:
> > >
> > > I did micro git-blame research here. I spotted only on
ny
> better ideas?
>
How about something like pg_stat_progress_replication_slot with remote
LSN/standby LSN/catalog XID etc?
Wouldn't this be in sync with all other debug pg_stat_progress* views
and thus more Postgres-y?
--
Best regards,
Kirill Reshke
e discussion in this
thread, and it looks like no one was bothered about these lines or VM
logging changes (in this exact pin buffer aspect). The discussion was
of other aspects of this commit.
[0] https://github.com/postgres/postgres/commit/2c03216d8311
[1] https://www.postgresql.org/message-id/533D6CBF.6080203%40vmware.com
--
Best regards,
Kirill Reshke
o support this in this patch series.
I can even send v5-0004 with this support in the thread if that's
okay.
--
Best regards,
Kirill Reshke
On Sat, 23 Aug 2025 at 19:57, Peter Eisentraut wrote:
>
> On 22.08.25 11:59, Álvaro Herrera wrote:
> > On 2025-Aug-22, Kirill Reshke wrote:
> >
> >> I am uncertain about the delineation between when we make changes and
> >> when we refrain from doing so.
> &
On Thu, 28 Aug 2025 at 08:35, jian he wrote:
>
> That means, we don't need to change the ATPrepDropExpression function
> argument for now?
Sure. V3 with this attached, and I think we can move cf entry to RFC
--
Best regards,
Kirill Reshke
v3-0001-Fix-ALTER-TABLE-DROP-E
n be used to satisfy this qual
(3) Using Cost Model for filtering best options
All of this can not be done with your approach?
Cost model can give hints to the optimizer that this TAM will process
some qual much faster than any by-index access. Smart cost
model/optimizer can realise that selecting only few of all attributes
from column-orietired relation + filter when using SIMD etc can be
really cheap.
So maybe the good shape of this patch would be something that could
choose between seqscan and indexscan in planner time?
--
Best regards,
Kirill Reshke
> > > > This patch enables suggestions after each comma, improving usability
> > > > > when specifying
> > > > > multiple options.
> > > > >
> > > > > Although not directly related to the main proposal, I believe this is
> > > > > a helpful enhancement
> > > > > to COPY tab completion and included it here for completeness.
> > > > >
> > > > > I’d appreciate your review and feedback on this series.
>
> The previous patch was broken failed to complie since I missed following
> the required format of if-conditions in match_previous_words().
> I've attached update patches.
>
> Regards,
> Yugo Nagata
>
> --
> Yugo Nagata
Hi! This tab completion support is indeed very useful. Thanks for
working on this.
I spotted potential improvement here: current v5 does not support COPY
completion for a pattern I do frequently use:
specifying COPY options without WITH clause e.g. "copy yy from
'/home/reshke/cpg/csv.csv' " Is not completed with BINARY, CSV,
DELIMITER etc.
--
Best regards,
Kirill Reshke
hanged much. So, while not resulting in query speedup, this can
save CPU.
Maybe we can derive an artificial benchmark, which will show query
speed up, but for now I dont have one.
--
Best regards,
Kirill Reshke
without:
Overhead Shared Ob Symbol
7.13% postgres [.] heap_page_prune_and_freeze
anage to reproduce such behaviour though.
+ if ((vmflags & VISIBILITYMAP_VALID_BITS) != 0)
+ {
+ Assert(!PageIsAllVisible(page));
+ set_pd_all_vis = true;
+ LockBuffer(vmbuffer, BUFFER_LOCK_EXCLUSIVE);
+ PageSetAllVisible(page);
+ visibilitymap_set_vmbyte(vacrel->rel,
+ blkno,
+
--
Best regards,
Kirill Reshke
asted from visibilitymap_set, but maybe
display "flags" also?
4) visibilitymap_set receives XLogRecPtr recptr parameters, which is
set to WAL record lsn during recovery and to InvalidXLogRecPtr
otherwise. visibilitymap_set manages VM page LSN bases on this recptr
value (inside function logic). visibilitymap_set_vmbyte behaves
vise-versa and makes its caller responsible for page LSN management.
Maybe we should keep these two functions akin to each other?
--
Best regards,
Kirill Reshke
Looks like no CF entry for this thread.
CF entry [0] created.
[0] https://commitfest.postgresql.org/patch/5992/
--
Best regards,
Kirill Reshke
R COLUMN d DROP EXPRESSION;
ERROR: ALTER TABLE / DROP EXPRESSION must be applied to child tables too
HINT: Do not specify the ONLY keyword.
reshke=!# rollback ;
ROLLBACK
```
--
Best regards,
Kirill Reshke
v2-0001-Fix-ALTER-TABLE-DROP-EXPRESSION-with-inheritance-.patch
Description: Binary data
changes and I agree with them.
The only aspect that drew my attention is in the following sentence:
>+ but instead goes into an aborted state. While in this state all commands
>except
> + and are
> ignored
We can also do ABORT;
Is this worth noting?
--
Best regards,
Kirill Reshke
On Fri, 22 Aug 2025 at 14:46, Álvaro Herrera wrote:
>
> On 2025-Aug-21, Kirill Reshke wrote:
>
> > I wouldn’t say this is misleading, but " a single relation" is indeed
> > not precise enough. IMO we need a more precise term to distinguish
> > regular rela
ally. This can break some
third-party query analysing tools (as it changes format). Can we make
this optional?
--
Best regards,
Kirill Reshke
DOMAIN
>
> v6-0003-CREATE-SCHEMA-CREATE-COLLATION.patch
> for CREATE SCHEMA ... CREATE-COLLATION
With these patches applied:
```
reshke=# create schema sh1 create type tp as (i text);
ERROR: unrecognized node type: 226
```
Without patches it will be a syntax error.
Also we need a better error message in this:
"CREATE SCHEMA ... CREATE OBJECT currently not support for..."
First of all, is it s/support/supported/ ? Also would vote for
something like "%s is not yet supported inside schema definition."
WDYT?
--
Best regards,
Kirill Reshke
but I see there is a little
chance of this committed.
[0]
https://github.com/postgres/postgres/blob/13b935c/src/backend/access/heap/heapam_xlog.c#L1007-L1050
[1]
https://github.com/postgres/postgres/blob/13b935c/src/backend/access/heap/heapam_xlog.c#L1083-L1121
--
Best regards,
Kirill Reshke
also this error check seems duplicated in CreateStatistics?
>
Indeed.
--
Best regards,
Kirill Reshke
Hi!
I was looking at how PostgreSQL handles VM map bits, when I noticed $subj.
PFA small refactoring patch.
--
Best regards,
Kirill Reshke
v1-0001-Remove-unneeded-cast-in-heap_xlog_lock.patch
Description: Binary data
xt_pageno, true, next);
+ next_offptr = (MultiXactOffset *)
MultiXactOffsetCtl->shared->page_buffer[next_slotno];
+ next_offptr[next_entryno] = offset + nmembers;
should we check the value of next_offptr[next_entryno] to be equal to
zero or offset + nmembers ? Assert or
errcode(ERRCODE_DATA_CORRUPTED) also.
--
Best regards,
Kirill Reshke
rence
in by-hand testing.
[0] https://www.postgresql.org/message-id/aKT7qD0VkGhQgFJe%40paquier.xyz
--
Best regards,
Kirill Reshke
v1-0001-Remove-condition-variables-from-injection-wait-lo.patch
Description: Binary data
nstraints didn't find any more missed cases, but (1) still
> feels like the right level of cautiousness. If there are no objections in the
> next 3hr, I'll proceed with (1).
>
Hi! I can see we have option (1) (28e7252 etc). Can we now move
forward with option (2) for HEAD?
--
Best regards,
Kirill Reshke
On Wed, 20 Aug 2025 at 00:50, Tom Lane wrote:
>
> Kirill Reshke writes:
> > I revert this commit (these were conflicts but i resolved them) and
> > added assert for crit sections in WaitEventSetWait.
>
> Your patch still contains some conflict markers :-(. Attached
On Tue, 19 Aug 2025 at 23:08, Tom Lane wrote:
>
> Kirill Reshke writes:
> > On Tue, 19 Aug 2025 at 21:16, Yura Sokolov wrote:
> >> `if (CritSectionCount != 0) _exit(2) else proc_exit(1)` in
> >> WaitEventSetWaitBlock () solves the issue of inconsistency IF POS
re hung indefinitely while waiting for
(already dead logger), might be a rare one.
The problem is, even without a logger, on current HEAD, we will fail
to stop the system when PM dies, and there is no simple fix.
It would be very helpful if LWLock implementation was done using latch
wait, there will be no problem then.
But we are where we are, so I can see there is a sense in making a try
to notify other processes that we are going to die soon and they need
to do the same (through shared memory), and then _exit(1).
--
Best regards,
Kirill Reshke
(since postmaster will SIGKILL its children).
>
This fix was proposed in this thread. It fixes inconsistency but it
replaces one set of problems
with another set, namely systems that fail to shut down.
--
Best regards,
Kirill Reshke
at this state probability is much higher
due to the aforementioned commit. In can happen with almost
any OOM on highly loaded systems.
--
Best regards,
Kirill Reshke
[0]
https://www.postgresql.org/message-id/CALdSSPgDAyqt%3DORyLMWMpotb9V4Jk1Am%2Bhe39mNtBA8%2Ba8TQDw%40mail.gmail.com
--
Best regards,
Kirill Reshke
On Tue, 19 Aug 2025 at 14:14, Kirill Reshke wrote:
>
> This thread is a candidate for [0]
>
>
> [0]https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
>
Let me summarize this thread for ease of understanding of what's going on:
Timeline:
1) Andrey Borodin sends a pa
ssibly) increasing the
number of reviewers.
[0] https://commitfest.postgresql.org/55/new/
--
Best regards,
Kirill Reshke
This thread is a candidate for [0]
[0]https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
Best regards,
Kirill Reshke
eem right: you'd keep waiting for the CV, but the backend
> that would wake you might have exited.
I revert this commit (these were conflicts but i resolved them) and
added assert for crit sections in WaitEventSetWait.
make check passes (without v2-0001 it fails)
--
Best regards,
ckends blocked in LWLockAcquire(x) hang forever, after
> > someone who holds x calls _exit()?
>
> If someone who holds x is killed by (say) the OOM killer, how do
> we get out of that?
+1, if we kill-9 PM and then immediately kill-9 lwlock holder, there
is no way for system to shutdown (both HEAD and back branches).
So we can ignore this case.
--
Best regards,
Kirill Reshke
oop until we've determined whether we could acquire the lock or not */
while (true)
{
if (old_state & (1<< LW_WS_OWNER_DEAD)) _exit(2) /* or maybe proc_exit(1)*/
....
if (pg_atomic_compare_exchange_u32(&lock->state, &old_state, desired_state))
...
/*rerty*/
}
```
I am not sure this idea is workable though.
--
Best regards,
Kirill Reshke
775807 | 1 | no | 1
Access method: aa
```
--
Best regards,
Kirill Reshke
describe_enhasement.diff
Description: Binary data
COMPLETE_WITH("INDEX", "TABLE", "SEQUENCE");
/* Complete "CREATE ACCESS METHOD TYPE " */
else if (Matches("CREATE", "ACCESS", "METHOD", MatchAny,
"TYPE", MatchAny))
COMPLETE_WITH("HANDLER");
```
--
Best regards,
Kirill Reshke
--
Best regards,
Kirill Reshke
make attached work. The idea to
"escalate" proc_exit to immediately exit via syscall comes to my mind
from how elog(ERROR) behaves in CRIT sections (every elog(ERROR)
efficiently becomes elog(PANIC)).
--
Best regards,
Kirill Reshke
v2-0001-Do-not-exit-on-postmaster-death-even-inside-CRI
.postgresql.org/message-id/20150508192921.GM2523%40alvh.no-ip.org
--
Best regards,
Kirill Reshke
AINT",
MatchAny, "NOT", "NULL"))
COMPLETE_WITH("NOT VALID");
```
Anyway, this is purely optional and can be a separate topic.
I propose to focus on Alvaro's feedback for now.
--
Best regards,
Kirill Reshke
Hi! Thank you for putting attention to this.
On Sun, 17 Aug 2025 at 19:33, Tom Lane wrote:
>
> Kirill Reshke writes:
> > [ v1-0001-Do-not-exit-on-postmaster-death-ever-inside-CRIT-.patch ]
>
> I do not like this patch one bit: it will replace one set of problems
> wit
ata';
> EOF
>
> master -> patch
> 6.2 minutes -> 5 minutes : ~20% reduction
>
> A 15% improvement can be noticed with the same benchmark but 4 workers.
>
> - Melanie
In only get 5-10% improvements
I did this benchmark also. For 16 source data files that are 150MB
each I get 5-10 % speedup (5% with small shared_buffers and 10 % with
big shared_buffers).
--
Best regards,
Kirill Reshke
stgres-y
way to me.
--
Best regards,
Kirill Reshke
r maybe
`pg_show_{objecttype}_ddl` design.
--
Best regards,
Kirill Reshke
.
Otherwise LGTM.
I did not review the new 0003-0007 series. Will try to find the time
to do this.
--
Best regards,
Kirill Reshke
inges on
> the boolean 'is_tbl_desc'. Therefore, it seems more natural for the
> main condition to be "if (is_tbl_desc)" here.
>
> This turned everything inside out. PSA: a top-up patch to show a way
> to do this. Perhaps my implementation is a bit verbose, but OTOH
and noticed that `mode` column shows
`normal` for both auto-vacuum and user-initiated vacuum (via VACUUM
utility statement).
Is it ok? Maybe for more visibility we can display different values
for these two cases?
--
Best regards,
Kirill Reshke
l be better?
--
Best regards,
Kirill Reshke
e: we now can complete 'alter domain
... add constraint .. not null' with 'not valid'. This also could be
a separate patch.
--
Best regards,
Kirill Reshke
On Thu, 14 Aug 2025 at 10:41, Kirill Reshke wrote:
>
o I am trying to reproduce is following:
>
> 1) Some process p1 locks some buffer (name it buf1), enters CRIT
> section, calls MarkBufferDirty and hangs inside XLogInsert on CondVar
> in (GetXLogBuffer -> AdvanceXLInsertBuffer
, while the
xlog record that describes this change never makes it to disk. This is
very bad.
To be clear, I am trying to avoid use of inj points to reproduce
corruption. I am not yet successful in this though.
--
Best regards,
Kirill Reshke
That should
be a separate patch though.
Also, SET suggests SESSION but not LOCAL, which also can be improved
--
Best regards,
Kirill Reshke
tions during
critical sections, so it is unclear to me why we should handle
postmaster death any differently.
[0]
https://github.com/postgres/postgres/blob/393e0d2314050576c9c039853fdabe7f685a4f47/src/backend/storage/ipc/waiteventset.c#L1260-L1261
--
Best regards,
Kirill Reshke
it
possible that AIO is somehow involved here?
--
Best regards,
Kirill Reshke
o disk here, isn’t ? PFA strace.
--
Best regards,
Kirill Reshke
reshke@yezzey-cbdb-bench:~/cpg$ sudo strace -p 354 -yyy -ttt -vvv -k
strace: Process 354 attached
1754979581.797532 epoll_wait(6, [{events=EPOLLIN,
data={u32=2600145240, u64=97498357764440}}], 1, -1) = 1
> /usr/lib/x8
---
0 | t | t | f
(1 row)
```
Notice I moved INJECTION point one line above visibilitymap_clear.
Without this change, such behaviour also reproduced, but with much
less frequency.
--
Best regards,
Kirill Reshke
v2-0001-Corrupt-VM-on-standby.patch
Description: Binary data
ffect.
>
> also partitioned table check constraint (name, definition
> (pg_constraint.conbin) must match with partition
> otherwise partition can be attached to the partitioned table.
> so here you don't need to consider RELKIND_PARTITIONED_TABLE.
Hi!
I looked at v3.
Should we rename `ATExecAlterConstrEnforceability` to
`ATExecAlterFKConstrEnforceability `?
--
Best regards,
Kirill Reshke
PostgreSQL's grammar support, yet this particular case is
relatively simple to support. So, should we add this feature?
Please let me know your thoughts.
[0]
https://www.postgresql.org/message-id/CACJufxFY%3DGkptsiH8X%3DVdyYAnNE_%3Du5j6WyDufTste6CuzRvnw%40mail.gmail.com
--
Best regards,
Kirill R
onversion is needed.
> */
>
> I slightly modified the top and bottom comments as well. (In the top
> comment, I added "Other" because we have the definitions of members
> such as ri_ChildToRootMap and ri_RootToChildMap above.)
>
> Comments welcome!
>
> Best regards,
> Etsuro Fujita
>
>
Hi! Looks like you forgot to actually attach a patch file?
--
Best regards,
Kirill Reshke
o then I can check it once.
The only doc on this that I am aware of is [0]. The project is however
more dead than alive, but I hope this is just a temporary stop of
development, not permanent.
[0] https://wiki.postgresql.org/wiki/Parallel_Recovery
--
Best regards,
Kirill Reshke
-in subsystem for transaction dependency tracking would be highly
beneficial for physical replication speedup projects like[0]
>
> Thoughts?
Surely we need to give it a try.
[0] https://github.com/koichi-szk/postgres
--
Best regards,
Kirill Reshke
t without changes in pg_dump_sort.c, 002_pg_upgarde
fails and with changes it does not.
PFA. I am not horribly sure about my additions to the
`src/test/regress/sql/privileges.sql` file, maybe appending SQL to the
end of the file is not the best option and there is a better place.
--
Best regards,
Kirill Resh
pg_dump_sort.c:454: DOTypeNameCompare: Assertion `0' failed.
I reproduced this. Indeed, in case of default acl we happen to use OID sort.
PFA resolves this issue. I simply added DEFAULT ACL case-specific
tiebreaker that resolves object order.
--
Best regards,
Kirill Reshke
0001-Handle-DEFAULT-ACL-case-in-DOTypeNameCompare-functio.patch
Description: Binary data
EEiYGbxiXp2mh5KCA%40mail.gmail.com
--
Best regards,
Kirill Reshke
est regards,
Kirill Reshke
Best regards,
Kirill Reshke
rds,
Kirill Reshke
0001-Allow-to-explicitly-set-REPLICA-IDENTITY-with-relati.patch
Description: Binary data
ble to manipulate with PGDATA without starting
> Postgres.
--
Best regards,
Kirill Reshke
On Thu, 10 Apr 2025 at 17:37, jian he wrote:
>
>
> I think the current test example is fine.
Ok, let it be so. I changed status to RFQ as I have no more input
here, and other reviewers in thread remain silent (so I assume they
are fine with v10)
--
Best regards,
Kirill Reshke
on callable in production systems?
One more concern is about pre-defined oids: they are limited. Maybe we
should not consume predefined oid in case when this is avoidable.
--
Best regards,
Kirill Reshke
There is actually a prod-ready (non open source) implementation of
RAFT as extension, called BiHA, by pgpro.
Just some thought on top of my mind, if you need my voice here.
--
Best regards,
Kirill Reshke
; this functionality proves particularly useful.
>
> Thank you for your time and assistance. I look forward to your response.
>
> Sincerely,
>
> jack.
Have you read https://www.postgresql.org/docs/current/sql-savepoint.html
? There are a few examples here.
--
Best regards,
Kirill Reshke
I'm not aware of.
```
ALTER TABLE gtest22c DROP COLUMN e;
\d gtest22c
-- EXPLAIN (COSTS OFF) SELECT * FROM gtest22c WHERE b * 3 = 6;
-- SELECT * FROM gtest22c WHERE b * 3 = 6;
-- EXPLAIN (COSTS OFF) SELECT * FROM gtest22c WHERE a = 1 AND b > 0;
-- SELECT * FROM gtest22c WHERE a = 1 AND b > 0;
```
--
Best regards,
Kirill Reshke
On Fri, 11 Apr 2025 at 00:33, David G. Johnston
wrote:
>
> They are supported for the From variant; valid completions need only satisfy
> one of to/from, not both.
>
Thank you. If so, then WFM, and I don't have any more objections.
--
Best regards,
Kirill Reshke
On Thu, 10 Apr 2025 at 20:07, Fujii Masao wrote:
>
>
>
> On 2025/04/09 19:24, Kirill Reshke wrote:
> > On Wed, 9 Apr 2025 at 14:45, Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2025/04/09 18:25, Kirill Reshke wrote:
> &g
On Fri, 4 Apr 2025, 16:41 Kirill Reshke, wrote:
> On Thu, 3 Apr 2025 at 20:07, Kirk Wolak wrote:
> > Worse, "select pg_stat_st" has no clue. I was looking for ...
> _reset
> >
> > It's not that difficult to add, I am suggesting that we use the same
&
pp (year int, day int) PARTITION BY RANGE (year);
+CREATE TABLE pp_1 (year int, day int) PARTITION BY RANGE (day);
+CREATE TABLE pp_2 (year int, day int) PARTITION BY RANGE (day);
??
--
Best regards,
Kirill Reshke
bNZAp-DCmwvOE_Gkogb%2Brhfqqe1%3DS5cOHR-V7Q%40mail.gmail.com
--
Best regards,
Kirill Reshke
On Wed, 9 Apr 2025 at 14:45, Fujii Masao wrote:
>
>
>
> On 2025/04/09 18:25, Kirill Reshke wrote:
> > On Wed, 9 Apr 2025 at 13:23, jian he wrote:
> >>
> >> hi.
> >>
> >> we allow the "COPY table TO" command to copy rows from materia
; Mattias after I wrote that. If not, I'll move it to the next CF.
Looks like no more patches will get into v18 so i moved the CF
--
Best regards,
Kirill Reshke
s/errcodes.h" [m [K
| [01;31m [K^~ [m [K
compilation terminated.
[0]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dogfish&dt=2025-04-08%2011%3A25%3A11
--
Best regards,
Kirill Reshke
On Fri, 4 Apr 2025, 15:17 Kirill Reshke, wrote:
> Hi!
>
> First of all, a commit message does not need to contain SQL examples
> of what it does. We should provide human-readable explanations and
> that's it.
>
> Next, about changes to src/test/regress/sql/copy2.sql. I
Sorry, wrong thread
Best regards,
Kirill Reshke
On Mon, 7 Apr 2025, 19:54 Kirill Reshke, wrote:
>
> On Fri, 4 Apr 2025, 15:17 Kirill Reshke, wrote:
>
>> Hi!
>>
>> First of all, a commit message does not need to contain SQL examples
>> of what it does.
ITION OF syntax? It is also one command instead of two (create +
alter). It is also hard to say what partition structure is, because
column names on different partition levels are the same, just order is
switched. Let's change it to something more intuitive too?
--
Best regards,
Kirill Reshke
s very questionable if this feature is worth it.
--
Best regards,
Kirill Reshke
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
>
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
1.20 times : 1921.724 ms (patches) vs
2343.393 ms (unpatched)
for 804 rows speedup is 1.10 times : 3932.361 ms (patches) vs
4358.489ms (unpatched)
So, this patch indeed speeds up some cases, but with larger tables
speedup becomes negligible.
--
Best regards,
Kirill Reshke
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
mentation specifics along the way. However,
this is merely my opinion on the matter.
--
Best regards,
Kirill Reshke
On Fri, 28 Mar 2025 at 21:26, Tomas Vondra wrote:
>
> Here's a polished version of the patches. If you have any
> comments/objections, please speak now.
> --
> Tomas Vondra
Hi, no objections, lgtm
--
Best regards,
Kirill Reshke
1 - 100 of 288 matches
Mail list logo
