Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

a problem that some type or function is taken from another regress test. For example, the table 'onek' is used in many regress tests. Regards, Damir Belyalov Postgres Professional From 0e1193e00bb5ee810a015a2baaf7c79e395a54c7 Mon Sep 17 00:00:00 2001 From: Damir Belyalov Date: F

Re: Extensibility of the PostgreSQL wire protocol

the positive impact of a pluggable protocol would be significant. -- Damir

Re: Extensibility of the PostgreSQL wire protocol

happens to also allow connecting to multiple databases from a single client connection => letting the client speak to the database [trough a proxy in this case] removed the bloated source of latency but kept the advantages.” -- Damir

Re: Extensibility of the PostgreSQL wire protocol

oo, a pluggable wire protocol would help with keeping tabs on individual backends). -- Damir

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

line 2, column m: "a" SELECT * FROM check_ign_err; n | m | k ---+---+--- 1 | 1 | 1 3 | 3 | 3 (2 rows) Regards, Damir пт, 10 дек. 2021 г. в 21:48, Pavel Stehule : > > > 2014-12-26 11:41 GMT+01:00 Pavel Stehule : > >> >> >> 2014-12-25 22:23 GMT+01:00 Alex

Proposal: http2 wire format

the way I am. Maybe even some of the GSoC students would take the implementation further? Damir

Re: Proposal: http2 wire format

> On 25 Mar 2018, at 19:42, David Fetter wrote: > > On Sat, Mar 24, 2018 at 06:52:47PM +0100, Damir Simunic wrote: >> Hello hackers, >> >> I’d like to propose the implementation of new wire protocol using http2 >> framing. > > Welcome to the PostgreSQL

Re: Proposal: http2 wire format

Hi, > On 26 Mar 2018, at 05:11, Craig Ringer wrote: > > On 26 March 2018 at 06:00, Damir Simunic wrote: > > > - Overhead for all clients. It may be tiny, but it needs to be > > measured and that cost needs to be weighed against the benefits. > > Maybe a

Re: Proposal: http2 wire format

tocol: the sooner we can get to stable h2 framing in the core, the sooner we’ll be able to experiment with new use cases and possibilities. Only then it will make sense to bring back this discussion about browsers, content negotiation, etc. Thanks, Damir > --Jacob

Re: Proposal: http2 wire format

> On 26 Mar 2018, at 11:34, Craig Ringer wrote: > > On 26 March 2018 at 17:01, Damir Simunic <mailto:damir.simu...@wa-research.ch>> wrote: > > > > - Doesn't break new clients connecting to old servers > > > > Old server sends “Invalid star

Re: Proposal: http2 wire format

> On 26 Mar 2018, at 12:47, Craig Ringer wrote: > > On 26 March 2018 at 17:34, Damir Simunic wrote: > > > > As you move forward with the PoC, consider: even if you decide not to > > become protocol-layer experts, you'll still need to become familiar > &

Re: Proposal: http2 wire format

> On 26 Mar 2018, at 11:13, Vladimir Sitnikov > wrote: > > Damir> * What are the criteria for getting this into the core? > Craig>Mine would be: > > +1 > > There's a relevant list as well: > https://github.com/pgjdbc/pgjdbc/blob/master/backend_pr

Re: Proposal: http2 wire format

issues that make sure the new protocol is 100% supporting all existing v3 use cases. Beyond v3 use cases, top of my mind are improvements like you comment on in the topic “Binary transfer” in your “v4 wanted features” doc (and most of the other stuff you mention). Damir > > Vladimir

Re: Proposal: http2 wire format

> On 26 Mar 2018, at 16:56, Tom Lane wrote: > > Damir Simunic writes: >>> On 26 Mar 2018, at 11:06, Vladimir Sitnikov >>> wrote: >>>> If anyone finds the idea of Postgres speaking http2 appealing > > TBH, this sounds like a proposal to expend

Re: Proposal: http2 wire format

> On 26 Mar 2018, at 18:19, Vladimir Sitnikov > wrote: > > Tom>But starting from the assumption that HTTP2 solves our problems seems to > me to be "Here's a hammer. > > Agree. Funny you agree with that—for someone having the experience of writing a driver and having a long list of things th

Re: Proposal: http2 wire format

> On 26 Mar 2018, at 15:42, Alvaro Hernandez wrote: > > > > On 26/03/18 13:11, Damir Simunic wrote: >>> On 26 Mar 2018, at 11:13, Vladimir Sitnikov >> <mailto:sitnikov.vladi...@gmail.com>> wrote: >>> >>> Damir> * What are the crit

Re: Proposal: http2 wire format

> On 26 Mar 2018, at 18:09, Vladimir Sitnikov > wrote: > > Damir>Postgres doesn’t know about grpc, s > > I'm afraid you are missing the point. > I would say PostgreSQL doesn't know about HTTP/2. > It is the same as "PostgreSQL doesn't know about

Re: Proposal: http2 wire format

blown protocol ontop of it. So no, this doesn't change that. If you had to nominate only one of those problems, which one would you consider the most interesting? Thanks for chiming in, really appreciate your time, Damir

Re: Proposal: http2 wire format

se/bind/exec" messages. I believe that is one of the requirements Craig > meant by "Is practical to implement in connection pooler proxies”. Why can’t I package this into a single request? Don’t modern web proxies deal with session affinity and stuff like that? > > Andre

Re: Proposal: http2 wire format

continued interest and support. Damir > > -- > Craig Ringer http://www.2ndQuadrant.com/ > <http://www.2ndquadrant.com/> > PostgreSQL Development, 24x7 Support, Training & Services

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

the system logfile with full detailed context. Maybe it's better to log only error message. file:///home/abc13/Documents/todo_copy/postgres/v2-0001-Add-COPY-option-IGNORE_DATATYPE_ERRORS.patch Regards, Damir Belyalov Postgres Professional diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgm

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

ke ""Error: %ld data type errors were > found" might be clearer. > Thanks. For more clearance change the message to: "Errors were found: %". Regards, Damir Belyalov Postgres Professional diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgml/ref/copy.sgml index c25

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

are not in kwlist.h and are not as keywords in gram.y. Regards, Damir Belyalov Postgres Professional

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

> > I might misunderstand something, but I believe the v5 patch uses > copy_generic_opt_list and it does not add IGNORE_DATATYPE_ERRORS as a > keyword. > It modifies neither kwlist.h nor gram.y. > Sorry, didn't notice that. I think everything is alright now. Regards,

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

https://dev.mysql.com/doc/refman/8.0/en/load-data.html https://docs.aws.amazon.com/redshift/latest/dg/r_COPY_command_examples.html Regards, Damir Belyalov Postgres Professional

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

e are inherited and be given. -- Regards, Damir Belyalov Postgres Professional

Output affected rows in EXPLAIN

7;t fixed regress tests yet. Regards, Damir Belyalov Postgres Professional From c6cbc6fa9ddf24f29bc19ff115224dd76e351db1 Mon Sep 17 00:00:00 2001 From: Damir Belyalov Date: Tue, 5 Sep 2023 15:04:01 +0300 Subject: [PATCH] Output affected rows in EXPLAIN. --- src/backend/commands/explain.c | 10 +

Re: Output affected rows in EXPLAIN

Update on a (cost=0.00..35.50 rows=0 width=0) -> Seq Scan on a (cost=0.00..35.50 rows=2550 width=10) (2 rows) UPDATE 0 Regards, Damir Belyalov Postgres Professional From c6cbc6fa9ddf24f29bc19ff115224dd76e351db1 Mon Sep 17 00:00:00 2001 From: Damir Belyalov Date: T

Redundant Unique plan node for table with a unique index

ld understand which set columns is unique for the every joinrel in query. In general terms I identified two cases when joinrel "saves" unique index from table: when tables are joined by unique index columns and when one table has unique index and it is "unique_for" (has one common tupl

Re: Redundant Unique plan node for table with a unique index

Thank you for feedback and thread [1]. Regards, Damir Belyalov Postgres Professional

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

data. Also it'll be interesting for me to list all cases when a hard error can be thrown. Regards, Damir Belyalov Postgres Professional From 0e1193e00bb5ee810a015a2baaf7c79e395a54c7 Mon Sep 17 00:00:00 2001 From: Damir Belyalov Date: Fri, 15 Sep 2023 11:14:57 +0300 Subject: [PATCH] ignore er

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

ormation?). There are 2 points why logging errors in logfile is better than logging errors in another file (e.g. PGDATA/copy_ignore_errors.txt). The user is used to looking for errors in logfile. Creating another file entails problems like: 'what file name to create?', 'do we need to make file rot

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

uot;wrong number of columns in row''. Do you offer to process input-function errors separately from other errors? Now all errors are processed in one "switch" loop in PG_CATCH, so this change can complicate code. Regards, Damir Belyalov Postgres Professional

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

> > Do you mean you stop dealing with errors concerned with constraints and > triggers and we should review 0006-COPY_IGNORE_ERRORS? > Yes, this patch is simpler and I think it's worth adding it first. > Hmm, I applied v6 patch and when canceled COPY by sending SIGINT(ctrl + > C), I faced the sam

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

Updated the patch due to conflicts when applying to master. > diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgml/ref/copy.sgml index c25b52d0cb..22c992e6f6 100644 --- a/doc/src/sgml/ref/copy.sgml +++ b/doc/src/sgml/ref/copy.sgml @@ -34,6 +34,7 @@ COPY { table_name [ ( format_name FREEZE [

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

Updated the patch: - Optimized and simplified logic of IGNORE_ERRORS - Changed variable names to more understandable ones - Added an analogue of MAX_BUFFERED_BYTES for safe buffer Regards, Damir Belyalov Postgres Professional > diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgml/

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

trig_before_part(); COPY check_ign_err FROM STDIN WITH IGNORE_ERRORS; WARNING: COPY check_ign_err, line 2: "2 2 2 2" WARNING: COPY check_ign_err, line 3: "3 3" WARNING: COPY check_ign_err, line 4, column n: "a" WARNING: COPY check_ign_err, line 5, column m: "b" W

Fwd: Merging statistics from children instead of re-sampling everything

n find out which values are most common and which are distinct. To calculate the partition densities, you can use the "Kernel density Estimation" - https://www.statsmodels.org/dev/examples/notebooks/generated/kernel_density html The approach may be very inaccurate and difficult to implement, but solves the problem. Regards, Damir Belyalov Postgres Professional

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

our case and it worked correctly. > BTW I may be overlooking it, but have you submit this proposal to the next CommitFest? Good idea. Haven't done it yet. Regards, Damir Postgres Professional From fa6b99c129eb890b25f006bb7891a247c8a431a7 Mon Sep 17 00:00:00 2001 From: Damir Belyalov Date:

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

> > > + /* Buffer was filled, commit subtransaction and prepare > to replay */ > > + ReleaseCurrentSubTransaction(); > What is actually being committed by this ReleaseCurrentSubTransaction()? > It seems to me that just safecstate->replay_buffer is fulfilled before > this

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

> From 09befdad45a6b1ae70d6c5abc90d1c2296e56ee1 Mon Sep 17 00:00:00 2001 From: Damir Belyalov Date: Fri, 15 Oct 2021 11:55:18 +0300 Subject: [PATCH] COPY_IGNORE_ERRORS with GUC for replay_buffer size --- doc/src/sgml/config.sgml | 17 ++ doc/src/sgml/ref/copy.s

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

Thank you for reviewing. In the previous patch there was an error when processing constraints. The patch was fixed, but the code grew up and became more complicated (0005-COPY_IGNORE_ERRORS). I also simplified the logic of safeNextCopyFrom(). You asked why we need subtransactions, so the answer is

Re: Implement missing join selectivity estimation for range types

Hello! Thank you for the patch, very interesting article. The patch doesn't apply to the current postgres version. Could you please update it? Regards, Damir Belyalov, Postgres Professional

Re: [feature]COPY FROM enable FORCE_NULL/FORCE_NOT_NULL on all columns

trs; i++) cstate->opt.force_notnull_flags[i] = true; } you can use MemSet(): if (cstate->opts.force_notnull_all) MemSet(cstate->opt.force_notnull_flags, true, num_phys_attrs * sizeof(bool)); The same for the force_null case. Regards, Damir Belyalov, Postgres Professional

Re: Code of Conduct plan

Please take me off this list. > On Sep 14, 2018, at 05:31, Chris Travers wrote: > > > > On Wed, Sep 12, 2018 at 10:53 PM Tom Lane > wrote: > I wrote: > > Stephen Frost mailto:sfr...@snowman.net>> writes: > >> We seem to be a bit past that timeline... Do we have an