Alvaro Herrera 于2024年9月21日周六 05:15写道：
> On 2024-Sep-20, Alvaro Herrera wrote:
>
> > Yeah, there's a bunch of conflicts in current master. I rebased
> > yesterday but I'm still composing the email for v4. Coming soon.
>
> Okay, so here is v4 with these problems fixed, including correct
> propaga
> I looked at this and thought that one thing you might want to consider
> is adjusting show_storage_info() to accept the size and type
> parameters so you don't have to duplicate the formatting code in
> show_recursive_union_info().
I agree and made necessary changes. See attached v4 patches.
>
On Mon, 23 Sept 2024 at 15:29, jian he wrote:
> Given the above context, I am still confused with this sentence in
> sql-analyze.html.
> "If ONLY is specified before the table name, only that table is analyzed."
>
> like in the above sql example, only_inh_parent's child is also being analyzed.
I
On Fri, Sep 20, 2024 at 10:53 PM Masahiko Sawada wrote:
>
> On Thu, Sep 19, 2024 at 10:46 PM Amit Kapila wrote:
> >
> > On Fri, Sep 20, 2024 at 5:13 AM David Rowley wrote:
> > >
> > > On Fri, 20 Sept 2024 at 05:03, Masahiko Sawada
> > > wrote:
> > > > I've done other benchmarking tests while c
On Sun, Sep 22, 2024 at 11:27 AM David Rowley wrote:
>
> On Fri, 20 Sept 2024 at 17:46, Amit Kapila wrote:
> >
> > On Fri, Sep 20, 2024 at 5:13 AM David Rowley wrote:
> > > In general, it's a bit annoying to have to code around this
> > > GenerationContext fragmentation issue.
> >
> > Right, and
On Mon, Sep 23, 2024 at 8:57 AM jian he wrote:
>
> database owners do not necessarily have schema USAGE privilege.
> -<<<>>>--
> create role alice NOSUPERUSER LOGIN;
> create role bob NOSUPERUSER LOGIN;
> create database test;
> alter database test owner to alice;
> GRA
On Sun, Sep 22, 2024 at 9:09 PM David Rowley wrote:
>
> v7-0002 is all my changes.
>
> I'd like to push this soon, so if anyone has any last-minute feedback,
> please let me know in the next few days.
>
drop table if exists only_inh_parent,only_inh_child;
CREATE TABLE only_inh_parent (a int , b
On Sun, Sep 22, 2024 at 1:38 PM David Rowley wrote:
> Just looking at the commit message:
>
> > The rationale is based on the assumption that incremental sort is
> > always faster than full sort when there are presorted keys, a premise
> > that has been applied in various parts of the code. This
On Mon, Sep 23, 2024 at 4:10 AM Peter Smith wrote:
>
> On Fri, Sep 20, 2024 at 2:26 PM Amit Kapila wrote:
> >
> > On Fri, Sep 20, 2024 at 4:16 AM Peter Smith wrote:
> > >
> > > On Fri, Sep 20, 2024 at 3:26 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Thu, Sep 19, 2024 at 2:32 AM Amit Kap
On Sat, Sep 21, 2024 at 3:19 AM Masahiko Sawada wrote:
>
> On Thu, Sep 19, 2024 at 9:26 PM Amit Kapila wrote:
> >
> > >
> > > OK. Let me give some examples below to help understand this idea.
> > >
> > > Please correct me if these are incorrect.
> > >
> > > Examples, when publish_generated_column
My review comments for v8-0001
==
contrib/pg_logicalinspect/pg_logicalinspect.c
1.
+/*
+ * Lookup table for SnapBuildState.
+ */
+
+#define SNAPBUILD_STATE_INCR 1
+
+static const char *const SnapBuildStateDesc[] = {
+ [SNAPBUILD_START + SNAPBUILD_STATE_INCR] = "start",
+ [SNAPBUILD_BUILDING_S
On Sun, 22 Sept 2024 at 23:09, David Rowley wrote:
> I'd like to push this soon, so if anyone has any last-minute feedback,
> please let me know in the next few days.
Many thanks for your updates and assistance.
Looks good. Agreed, I was probably too conservative in some of the
doc updates.
Tha
On Wed, Jun 5, 2024 at 9:56 PM Heikki Linnakangas wrote:
>
> ## Patch 3: Split RelationClearRelation into three different functions
>
> RelationClearRelation() is complicated. Depending on the 'rebuild'
> argument and the circumstances, like if it's called in a transaction and
> whether the relati
On Fri, 20 Sept 2024 at 01:55, Пополитов Владлен
wrote:
> Currently PostgreSQL built on 64-bit Windows has 2Gb limit for
> GUC variables due to sizeof(long)==4 used by Windows compilers.
> Technically 64-bit addressing for maintenance_work_mem is possible,
> but code base historically uses variabl
On Thu, 25 Jul 2024 at 02:42, Marat Bukharov wrote:
> V5 patch. I've added more tests with different bytea sizes
I just glanced over this patch. Are you still planning on working on
it? There's been no adjustments made since the last feedback you got
in early August.
Can you address Andrey's fee
On Tue, Sep 17, 2024 at 5:03 PM Corey Huinker wrote:
>>
>> 1. make sure these three functions: 'pg_set_relation_stats',
>> 'pg_restore_relation_stats','pg_clear_relation_stats' proisstrict to true.
>> because in
>> pg_class catalog, these three attributes (relpages, reltuples,
>> relallvisible) i
Hi Andres:
> On 2024-09-20 17:38:40 +0800, Andy Fan wrote:
>> static inline void
>> FullTransactionIdAdvance(FullTransactionId *dest)
>> {
..
>> }
>>
>> I understand this functiona as: 'dest->value++' increases the epoch when
>> necessary and we don't want use the TransactionId which is smaller
On Tue, 20 Aug 2024 at 03:48, Ilia Evdokimov
wrote:
> Let's assume that this check needs to remain, and the length check doesn't
> guarantee anything. However, I'm a bit concerned that there's a NULL check
> here, but it's missing in the clauselist_selectivity_ext() function. For the
> reasons
On Thu, 19 Sept 2024 at 22:17, Tatsuo Ishii wrote:
> Attached patch fixes 1 & 2.
I looked at this and thought that one thing you might want to consider
is adjusting show_storage_info() to accept the size and type
parameters so you don't have to duplicate the formatting code in
show_recursive_unio
Tomas Vondra writes:
> On 9/22/24 17:45, Tom Lane wrote:
>> #define FAST_PATH_GROUP(index) \
>> -(AssertMacro(((index) >= 0) && ((index) < FP_LOCK_SLOTS_PER_BACKEND)), \
>> +(AssertMacro((uint32) (index) < FP_LOCK_SLOTS_PER_BACKEND), \
>> ((index) / FP_LOCK_SLOTS_PER_GROUP))
> For t
On 9/22/24 17:45, Tom Lane wrote:
> Tomas Vondra writes:
>> I've finally pushed this, after many rounds of careful testing to ensure
>> no regressions, and polishing.
>
> Coverity is not terribly happy with this. "Assert(fpPtr = fpEndPtr);"
> is very clearly not doing what you presumably intende
On Mon, 23 Sept 2024 at 05:43, Shayon Mukherjee wrote:
> - Modified get_index_paths() and build_index_paths() to exclude disabled
> indexes from consideration during query planning.
There are quite a large number of other places you also need to modify.
Here are 2 places where the index should
On Fri, Sep 20, 2024 at 2:26 PM Amit Kapila wrote:
>
> On Fri, Sep 20, 2024 at 4:16 AM Peter Smith wrote:
> >
> > On Fri, Sep 20, 2024 at 3:26 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Sep 19, 2024 at 2:32 AM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Users can use a publication
Hello,
I realized there were some white spaces in the diff and a compiler warning
error from CI, so I have fixed those and the updated patch with v2 is now
attached.
Shayon
On Sun, Sep 22, 2024 at 1:42 PM Shayon Mukherjee wrote:
> Hello,
>
> Thank you for all the feedback and insights. Work wa
>
> > Long-term, we should consider integrating with a distributed time
> > service like AWS Time Sync Service. This ensures high accuracy and
> > scalability for demanding applications.
>
> > I think the pluggable access method should make > this possible, no?
> I am sorry that I did not explai
Hello,
Thank you for all the feedback and insights. Work was busy, so I didn't get
to follow up earlier.
This patch introduces the ability to enable or disable indexes using ALTER
INDEX
and CREATE INDEX commands.
Original motivation for the problem and proposal for a patch
can be found here[0]
On Sun, Sep 22, 2024 at 8:10 AM Marcos Pegoraro wrote:
> Em sáb., 21 de set. de 2024 às 18:42, Bruce Momjian
> escreveu:
>
>> I suggest you explain what changes would make the docs better (meaing
>> more useful).
>>
>
> So, if we have a "Compatibility/Translation/Feature Comparison/ ... with
> o
Tomas Vondra writes:
> I've finally pushed this, after many rounds of careful testing to ensure
> no regressions, and polishing.
Coverity is not terribly happy with this. "Assert(fpPtr = fpEndPtr);"
is very clearly not doing what you presumably intended. The others
look like overaggressive asse
Em sáb., 21 de set. de 2024 às 18:42, Bruce Momjian
escreveu:
> I suggest you explain what changes would make the docs better (meaing
> more useful).
>
Well, I think I already did this in this discussion.
Tom said that some functions were copied from Oracle, so it is ok to
mention them. I don't
On 9/21/24 01:31, shihao zhong wrote:
Nisha Moond writes:
Thoughts? Looking forward to hearing others' opinions!
Had a productive conversation with Amit Kaplia today about time skew
in distributed systems, and wanted to share some thoughts.
Essentially, we're grappling with the classic distri
On Fri, 20 Sept 2024 at 13:20, Michael Harris wrote:
> I have attached a new version of the patch with this feedback incorporated.
I looked over the v6 patch and I don't have any complaints. However, I
did make some minor adjustments:
* A few places said things like "and possibly partitions and/
On 9/22/24 10:50, Ants Aasma wrote:
> On Sat, 21 Sept 2024 at 21:33, Tomas Vondra wrote:
>> I've finally pushed this, after many rounds of careful testing to ensure
>> no regressions, and polishing. All changes since the version shared on
>> September 13 are only cosmetic - renaming a macro to
Thanks for the review.
> In pgstat_checkpointer.c, it looks like you missed adding
> CHECKPOINTER_COMP(slru_written) in pgstat_checkpointer_snapshot_cb().
Fixed it.
> +
> +
> +slru_written bigint
> +
> +
> +Number of SLRU buffers written during checkpoints
> On Sat, Sep 21, 2024 at 05:25:30PM GMT, Tom Lane wrote:
>
> Is there a way to get the llvm library's version at run time? If so
> we could consider building a new function to return that.
Yes, there is a C api LLVMGetVersion to get the major, minor and patch
numbers. The jit provider could be e
Hi,
> Hi,
>
> I would like to improve the following two points on the result outputs
> of pgbench related to faild transaction. The patch is attached.
>
> (1) Output per-script statistics even when there are no successful
> transaction if there is any failed transactions due to serialization
> o
On Sat, 21 Sept 2024 at 21:33, Tomas Vondra wrote:
> I've finally pushed this, after many rounds of careful testing to ensure
> no regressions, and polishing. All changes since the version shared on
> September 13 are only cosmetic - renaming a macro to keep it consistent
> with the other ones, cl
36 matches
Mail list logo
