On Wed, Jul 29, 2020 at 3:16 PM Dilip Kumar wrote:
>
>
> Thanks, please find the rebased patch set.
>
> --
> Regards,
> Dilip Kumar
> EnterpriseDB: http://www.enterprisedb.com
I was running some tests on this patch. I was generally trying to see how
the patch affects logical replication when do
On Wed, Jul 29, 2020 at 03:06:58PM +0900, Michael Paquier wrote:
> This is actually a bug fix, because we include in the docs some
> incorrect information, so it should be backpatched. If there are no
> objections, I'll take care of that.
And done.
--
Michael
signature.asc
Description: PGP sign
On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote:
>
> I still don't agree with this as proposed.
>
> + * For now, we don't allow parallel inserts of any form not even where the
> + * leader can perform the insert. This restriction can be uplifted once
> + * we allow the planner to generate paral
Hi,
On Fri, Jul 10, 2020 at 5:32 PM torikoshia wrote:
> - whether information for identifying parent-child relation is necessary
> or it's an overkill
I think it's important to understand the parent-child relationship of
the context.
Personally, I often want to know the following two things ..
-
On Tue, Jul 14, 2020 at 6:51 PM Thomas Munro wrote:
> In the meantime, here's a rebase of the more straightforward patches
> in the stack. These are the ones that deal only with fixed sets of
> file descriptors, and they survive check-world on Linux,
> Linux+EXEC_BACKEND (with ASLR disabled) and
On 2020/07/22 16:49, torikoshia wrote:
On 2020-07-20 13:57, torikoshia wrote:
As I proposed earlier in this thread, I'm now trying to add information
about generic/cudstom plan to pg_stat_statements.
I'll share the idea and the poc patch soon.
Attached a poc patch.
Thanks for the POC pat
On Thu, 30 Jul 2020 at 12:24, Fujii Masao wrote:
>
>
>
> On 2020/07/30 10:46, Michael Paquier wrote:
> > On Thu, Jul 30, 2020 at 08:44:26AM +0900, Fujii Masao wrote:
> >> Isn't it better to add the comment explaining why toast tables are
> >> excluded from the tab completion for vacuum while they
On Thu, Jul 30, 2020 at 3:54 AM Michael Paquier wrote:
>
> On Wed, Jul 29, 2020 at 06:35:41PM +0200, Julien Rouhaud wrote:
> > There's at least PREPARE TRANSACTION / COMMIT PREPARED / ROLLBACK
> > PREPARED that should be normalized too. I also don't think that we
> > really want to have different
On Wed, Jul 29, 2020 at 9:05 PM Justin Pryzby wrote:
> So my 2ndary suggestion is to conditionalize based on the method rather than
> value of space used.
What's the advantage of doing it that way?
--
Peter Geoghegan
On Wed, Jul 29, 2020 at 08:35:08PM -0700, Peter Geoghegan wrote:
> AFAICT sort (and IncrSort) don't fail to show a field value if it is
> zero. Rather, they consistently show "space used" (in non-text
> format), which can be either memory or disk space. Technically they
> don't violate the letter o
On Wednesday, July 29, 2020, Peter Geoghegan wrote:
> On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian wrote:
> > > There should be a note about this in the Postgres 13 release notes,
> > > for the usual reasons. More importantly, the "Allow hash aggregation
> > > to use disk storage for large aggr
On Mon, Jul 27, 2020 at 8:36 PM Justin Pryzby wrote:
> I don't know of a guideline for text format, but the issues I've raised for
> HashAgg and IncrSort are based on previous commits which change to "show field
> even if its value is zero" for non-text format:
But the non-text format for IncrSor
On Wed, Jul 29, 2020 at 9:41 PM Dave Cramer wrote:
> For logical replication there is no need to implement this, but others are
> using the pgoutput plugin for Change Data Capture. The reason they are
> using pgoutput is because it is guaranteed to be available as it is in core
> postgres.
>
> Im
On 2020/07/30 10:46, Michael Paquier wrote:
On Thu, Jul 30, 2020 at 08:44:26AM +0900, Fujii Masao wrote:
Isn't it better to add the comment explaining why toast tables are
excluded from the tab completion for vacuum while they are vacuumable?
Sounds sensible, still it does not apply only to
On Wed, Jul 29, 2020 at 7:48 PM Bruce Momjian wrote:
> Well, that seems to be repeating what is already in the docs for
> hash_mem_multiplier, which I try to avoid. One other direction is to
> put something in the incompatibilities section. Does that make sense?
I would prefer to put it next to
On Wed, Jul 29, 2020 at 07:00:43PM -0700, Peter Geoghegan wrote:
> On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian wrote:
> > > There should be a note about this in the Postgres 13 release notes,
> > > for the usual reasons. More importantly, the "Allow hash aggregation
> > > to use disk storage for
On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian wrote:
> > There should be a note about this in the Postgres 13 release notes,
> > for the usual reasons. More importantly, the "Allow hash aggregation
> > to use disk storage for large aggregation result sets" feature should
> > reference the new GUC
On Wed, Jul 29, 2020 at 06:35:41PM +0200, Julien Rouhaud wrote:
> There's at least PREPARE TRANSACTION / COMMIT PREPARED / ROLLBACK
> PREPARED that should be normalized too. I also don't think that we
> really want to have different entries for begin / Begin / BEGIN /
> bEgin and similar for many
On Thu, Jul 30, 2020 at 08:44:26AM +0900, Fujii Masao wrote:
> Isn't it better to add the comment explaining why toast tables are
> excluded from the tab completion for vacuum while they are vacuumable?
Sounds sensible, still it does not apply only to vacuum. I would go
as far as just adding a co
On Wed, Jul 29, 2020 at 03:34:22PM -0700, Peter Geoghegan wrote:
> Hi Bruce,
>
> On Fri, Jun 26, 2020 at 3:24 PM Bruce Momjian wrote:
> > Patch attached and applied to PG 13.
>
> I committed the hash_mem_multiplier GUC to Postgres 13 just now.
>
> There should be a note about this in the Postgr
On Wed, Jul 29, 2020 at 11:34:07PM +0200, Daniel Gustafsson wrote:
> Extreme cases for sure, but more importantly, there should be no cases when
> this would cause an increase wrt the status quo.
Yep.
> Maybe it'd be worth pre-computing by a first pass which tracks pinned objects
> in a bitmap; w
On Fri, Jul 10, 2020 at 6:55 PM Andrey M. Borodin wrote:
> Thanks! Fixed.
It's not a bug, but I think those 64 bit constants should be wrapped
in UINT64CONST(), following our convention.
I'm confused about these two patches: 0001 introduces
gist_point_fastcmp(), but then 0002 changes it to gist_
On Mon, Jul 27, 2020 at 5:55 PM Peter Geoghegan wrote:
> Pushed the hashagg_avoid_disk_plan patch -- thanks!
Pushed the hash_mem_multiplier patch as well -- thanks again!
As I've said before, I am not totally opposed to adding a true escape
hatch. That has not proven truly necessary just yet. Fo
On Wed, Jul 29, 2020 at 10:08 AM Jeff Davis wrote:
> Is there a reason that HyperLogLog doesn't use pg_leftmost_one_pos32()?
Yes: HyperLogLog predates pg_leftmost_one_pos32().
> I tried the following patch and some brief performance tests seem to
> show an improvement.
Makes sense.
How did you
On 2020/07/29 3:30, Pavel Stehule wrote:
út 28. 7. 2020 v 20:25 odesílatel Josef Šimánek mailto:josef.sima...@gmail.com>> napsal:
Thanks for the info. I am waiting for review. Is there any summary of
requested changes needed?
Maybe it is just noise - you wrote so you will resend a pa
I wrote:
> (I wonder if we need to try to make it faster. I'd supposed that the
> loop was cheap enough to be a non-problem, but with large enough
> documents maybe not? It seems like converting to a hash table could
> be worthwhile for a large doc.)
OK, I dug into Stephen's test case off-list.
On 2020/07/30 3:33, Justin Pryzby wrote:
On Wed, Jul 29, 2020 at 03:21:19PM +0900, Michael Paquier wrote:
On Wed, Jul 29, 2020 at 01:27:07PM +0900, Masahiko Sawada wrote:
Good catch. The patch looks good to me.
While this patch is logically correct. I think that we should try to
not incre
Hi Bruce,
On Fri, Jun 26, 2020 at 3:24 PM Bruce Momjian wrote:
> Patch attached and applied to PG 13.
I committed the hash_mem_multiplier GUC to Postgres 13 just now.
There should be a note about this in the Postgres 13 release notes,
for the usual reasons. More importantly, the "Allow hash agg
On Thu, Jul 30, 2020 at 1:36 AM Robert Haas wrote:
> On Wed, Jul 29, 2020 at 3:23 AM Thomas Munro wrote:
> > On Tue, Jul 14, 2020 at 9:12 AM Robert Haas wrote:
> > > A number of EDB customers have had this error crop on their tables for
> > > reasons that we have usually not been able to determi
> On 29 Jul 2020, at 10:32, Michael Paquier wrote:
>
> On Wed, Jul 01, 2020 at 06:24:18PM +0900, Michael Paquier wrote:
>> I am not sure either, still it looks worth thinking about it.
>> Attached is a rebased version of the last patch. What this currently
>> holds is just the switch to heap_mul
> On 1 Jul 2020, at 16:58, Alvaro Herrera wrote:
>
> On 2020-Jul-01, Daniel Gustafsson wrote:
>
>>> On 19 Mar 2020, at 08:55, Daniel Gustafsson wrote:
>>
>>> With no response for 2 weeks during the commitfest, I propose to move this
>>> to
>>> the next CF to allow time for discussions.
>>
>>
On Mon, Jul 20, 2020 at 5:02 PM Mark Dilger
wrote:
> I've made the options 'all-visible', 'all-frozen', and 'none'. It defaults
> to 'none'.
That looks nice.
> > I guess that
> > could still be expensive if there's a lot of them, but needing
> > ShareUpdateExclusiveLock rather than only Access
On Wed, Jul 29, 2020 at 03:21:19PM +0900, Michael Paquier wrote:
> On Wed, Jul 29, 2020 at 01:27:07PM +0900, Masahiko Sawada wrote:
> > Good catch. The patch looks good to me.
>
> While this patch is logically correct. I think that we should try to
> not increase more the number of queries used t
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi,
The patch looks good to me.
The new status of this patc
On Mon, Jun 22, 2020 at 8:27 AM Daniel Gustafsson wrote:
> Attached is a new version of the online checksums patch which, I hope, address
> most of the concerns raised in previous reviews. There has been a fair amount
> of fiddling done, so below is a summary of what has been done.
Here are a bu
Hi,
Please see below review of the
0001-Skip-empty-transactions-for-logical-replication.patch
The make check passes.
+ /* output BEGIN if we haven't yet */
+ if (!data->xact_wrote_changes)
+ pgoutput_begin(ctx, txn);
+
+ da
On Sat, 2020-07-25 at 17:52 -0700, Peter Geoghegan wrote:
> BTW, your HLL patch ameliorates the problem with my extreme "sorted
> vs
> random input" test case from this morning [1] (the thing that I just
> discussed with Tomas). Without the HLL patch the sorted case had 2424
> batches. With the HLL
Is there a reason that HyperLogLog doesn't use pg_leftmost_one_pos32()?
I tried the following patch and some brief performance tests seem to
show an improvement.
This came up because my recent commit 9878b643 uses HLL for estimating
the cardinality of spill files, which solves a few annoyances wi
On Wed, Jul 29, 2020 at 5:29 PM Martijn van Oosterhout
wrote:
>
>
> On Wed, 29 Jul 2020 at 15:40, Julien Rouhaud wrote:
>>
>> On Wed, Jul 29, 2020 at 2:42 PM Fujii Masao
>> wrote:
>> >
>> >
>> > Or, we should extend the existing query normalization to handle also DDL?
>>
>> +1, introducing DDL
On Fri, Jul 24, 2020 at 3:12 PM Soumyadeep Chakraborty
wrote:
> Ah yes. We should then have ALTER SYSTEM WAL {PERMIT|PROHIBIT}. I don't
> think we should say "READ ONLY" if we still allow on-disk file changes
> after the ALTER SYSTEM command returns (courtesy dirty buffer flushes)
> because it doe
On Wed, 29 Jul 2020 at 15:40, Julien Rouhaud wrote:
> On Wed, Jul 29, 2020 at 2:42 PM Fujii Masao
> wrote:
> >
> >
> > Or, we should extend the existing query normalization to handle also DDL?
>
> +1, introducing DDL normalization seems like a better way to go in the
> long run. Defining what s
On 2020/04/03 22:49, James Coleman wrote:
On Thu, Apr 2, 2020 at 5:53 PM David Zhang wrote:
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentati
On 2020/05/06 22:49, Asif Rehman wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
The patch applies cleanl
‐‐‐ Original Message ‐‐‐
On Saturday, July 25, 2020 2:41 AM, vignesh C wrote:
> On Thu, Jul 16, 2020 at 7:35 PM Georgios gkokola...@protonmail.com wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Saturday, July 11, 2020 3:16 PM, vignesh C vignes...@gmail.com wrote:
> >
> > > On Mon
On Fri, Jul 24, 2020 at 1:18 PM Tom Lane wrote:
> The real bottom line is: if you don't want to do this, how else do
> you want to fix the problem? I'm no longer willing to deny that
> there is a problem.
That's the wrong question. The right question is whether we're
sufficiently certain that a
On Sun, Jul 26, 2020 at 1:27 PM Chris Travers wrote:
> The first (probably the best) would be a solution along the lines of yours
> along with a session-level GUC variable which could determine whether case
> branches can fold constants.
Bluntly, that seems like a terrible idea. It's great if y
On Sun, Jul 26, 2020 at 7:24 AM Amit Kapila wrote:
> No, "git diff --check" doesn't help. I have tried pgindent but that
> also doesn't help neither was I expecting it to help. I am still not
> able to figure out how I goofed up this but will spend some more time
> on this. In the meantime, I h
On Wed, Jul 29, 2020 at 2:42 PM Fujii Masao wrote:
>
> On 2020/07/29 18:24, Martijn van Oosterhout wrote:
> > Hoi hackers,
> >
> > We've been using the pg_stat_statements extension to get an idea of the
> > queries used in the database, but the table is being filled with entries
> > like:
> >
>
On Wed, Jul 29, 2020 at 3:23 AM Thomas Munro wrote:
> On Tue, Jul 14, 2020 at 9:12 AM Robert Haas wrote:
> > A number of EDB customers have had this error crop on their tables for
> > reasons that we have usually not been able to determine. In many
>
> Do you happen to know if they ever used the
On 2020/07/29 18:24, Martijn van Oosterhout wrote:
Hoi hackers,
We've been using the pg_stat_statements extension to get an idea of the queries
used in the database, but the table is being filled with entries like:
SAVEPOINT sa_savepoint_NNN;
RELEASE SAVEPOINT sa_savepoint_NNN;
DECLARE "c_7
On 2020/07/28 20:35, Hamid Akhtar wrote:
There have been no real objections on this patch and it seems to work.
Thanks! So I pushed the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On Wed, Jul 22, 2020 at 8:47 AM Mark Dilger
wrote:
>
>
>
> > On Jul 18, 2020, at 1:00 AM, John Naylor
> > wrote:
> >
> > pg_get_keywords() should probably have a column to display ability to
> > act as a bare col label. Perhaps a boolean? If so, what do you think
> > of using true/false for the
On Fri, Jul 24, 2020 at 10:40 PM Soumyadeep Chakraborty <
soumyadeep2...@gmail.com> wrote:
> On Thu, Jul 23, 2020 at 10:14 PM Amul Sul wrote:
> >
> > On Fri, Jul 24, 2020 at 6:28 AM Soumyadeep Chakraborty <
> soumyadeep2...@gmail.com> wrote:
> > > In case it is necessary, the patch set does not w
On Wed, Jul 29, 2020 at 06:41:16PM +0900, Masahiko Sawada wrote:
> whereas Query_for_list_of_vacuumables should search for:
>
> RELKIND_RELATION
> RELKIND_PARTITIONED_TABLE
> RELKIND_MATVIEW
> RELKIND_TOASTVALUE
FWIW, I don't think that we should make toast relations suggested to
the user at all
On Wed, 29 Jul 2020 at 15:21, Michael Paquier wrote:
>
> On Wed, Jul 29, 2020 at 01:27:07PM +0900, Masahiko Sawada wrote:
> > Good catch. The patch looks good to me.
>
> While this patch is logically correct. I think that we should try to
> not increase more the number of queries used to scan pg_
On Wed, Jul 29, 2020 at 08:42:27AM +, Lu, Chenyang wrote:
> When I was using PostgreSQL, I noticed that the output of the
> Japanese messages was inconsistent with the English messages.
> The Japanese message needs to be modified,so I made the patch.
Indeed, good catch. This needs to be appl
Hoi hackers,
We've been using the pg_stat_statements extension to get an idea of the
queries used in the database, but the table is being filled with entries
like:
SAVEPOINT sa_savepoint_NNN;
RELEASE SAVEPOINT sa_savepoint_NNN;
DECLARE "c_7f9451c4dcc0_5" CURSOR WITHOUT HOLD ...
FETCH FORWARD 250
Hi,hackers
When I was using PostgresQL, I noticed that the output of the Japanese messages
was inconsistent with the English messages.
The Japanese message needs to be modified,so I made the patch.
See the attachment for the patch.
Best regards
ja_po.patch
Description: ja_po.patch
On 7/29/20 1:03 PM, Amit Langote wrote:
Hi Andrey,
Thanks for updating the patch. I will try to take a look later.
On Wed, Jul 22, 2020 at 6:09 PM Andrey V. Lepikhov
wrote:
On 7/16/20 2:14 PM, Amit Langote wrote:
* Why the "In" in these API names?
+ /* COPY a bulk of tuples into a foreig
On Wed, Jul 01, 2020 at 06:24:18PM +0900, Michael Paquier wrote:
> I am not sure either, still it looks worth thinking about it.
> Attached is a rebased version of the last patch. What this currently
> holds is just the switch to heap_multi_insert() for the three catalogs
> pg_attribute, pg_depend
Hi Andrey,
Thanks for updating the patch. I will try to take a look later.
On Wed, Jul 22, 2020 at 6:09 PM Andrey V. Lepikhov
wrote:
> On 7/16/20 2:14 PM, Amit Langote wrote:
> > * Why the "In" in these API names?
> >
> > + /* COPY a bulk of tuples into a foreign relation */
> > + BeginFore
On 17.06.2020 09:14, k.jami...@fujitsu.com wrote:
Hi,
Since the last posted version of the patch fails, attached is a rebased version.
Written upthread were performance results and some benefits and challenges.
I'd appreciate your feedback/comments.
Regards,
Kirk Jamison
As far as i understa
On Tue, Jul 14, 2020 at 9:12 AM Robert Haas wrote:
> A number of EDB customers have had this error crop on their tables for
> reasons that we have usually not been able to determine. In many
Do you happen to know if they ever used the
snapshot-too-old feature?
On Wed, Jul 29, 2020 at 6:15 PM Thomas Munro wrote:
> +static inline FullTransactionId
> +FullXidViaRelative(FullTransactionId rel, TransactionId xid)
>
> I'm struggling to find a better word for this than "relative".
The best I've got is "anchor" xid. It is an xid that is known to
limit nextFul
64 matches
Mail list logo
