Re: [HACKERS] [PATCH] Generic type subscripting

> On 14 November 2017 at 22:25, Dmitry Dolgov <9erthali...@gmail.com> wrote: > But now I wonder if `resnull` is really needed in `jsonb_get_element`, > `array_get_element` and it seems to me that I can even get rid of it so On the second thought, no, looks like I'm wrong and it

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

> On 12 September 2017 at 15:29, Tom Lane wrote: > > This patch no longer applies cleanly on HEAD, so here's a rebased version > (no substantive changes). As before, I think the most useful review task > would be to quantify whether it makes planning noticeably slower. I

Re: [HACKERS] [PATCH] Generic type subscripting

> On 19 November 2017 at 16:13, Arthur Zakirov wrote: > > I think it is time to mark the patch as "Ready for Commiter". I've > marked it. Good, thank you for the comprehensive review.

Re: [HACKERS] [PATCH] Generic type subscripting

> On 16 November 2017 at 12:40, Arthur Zakirov wrote: > > Actually it is not only way to return isnull information. What i've meant is that it's the only way if we want to keep the function signature. Actually I would prefer this (container, internal) -> extracted

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On 3 April 2018 at 15:34, Ashutosh Bapat > wrote: > On Fri, Mar 30, 2018 at 7:36 PM, Ashutosh Bapat > wrote: >> >> I am working on commenting portions of the code to make it more clear >> and readable. Will update the patches

Re: libpq compression

> On 30 March 2018 at 14:53, Konstantin Knizhnik wrote: > Hi hackers, > One of our customers was managed to improve speed about 10 times by using SSL compression for the system where client and servers are located in different geographical regions > and query results

Re: Postgres, fsync, and OSs (specifically linux)

> On 22 May 2018 at 03:08, Andres Freund wrote: > On 2018-05-19 18:12:52 +1200, Thomas Munro wrote: >> On Sat, May 19, 2018 at 4:51 PM, Thomas Munro >> wrote: >> > Next, make check hangs in initdb on both of my pet OSes when md.c >> > raises an

Re: Postgres, fsync, and OSs (specifically linux)

> On 22 May 2018 at 20:59, Andres Freund <and...@anarazel.de> wrote: > On 2018-05-22 20:54:46 +0200, Dmitry Dolgov wrote: >> > On 22 May 2018 at 18:47, Andres Freund <and...@anarazel.de> wrote: >> > On 2018-05-22 08:57:18 -0700, Andres Freund wrote: >> &g

Re: Postgres, fsync, and OSs (specifically linux)

> On 22 May 2018 at 18:47, Andres Freund <and...@anarazel.de> wrote: > On 2018-05-22 08:57:18 -0700, Andres Freund wrote: >> Hi, >> >> >> On 2018-05-22 17:37:28 +0200, Dmitry Dolgov wrote: >> > Thanks for the patch. Out of curiosity I tried to play wit

Re: assert in nested SQL procedure call in current HEAD

> On 8 June 2018 at 06:20, Andrew Gierth wrote: > Joe> My colleague Yogesh Sharma discovered an assert in nested SQL > Joe> procedure calls after ROLLBACK is used. Minimal test case and > Joe> backtrace below. I have not yet tried to figure out exactly what > Joe> is going on beyond seeing

Re: jsonb iterator not fully initialized

> On 26 May 2018 at 16:47, Andrew Dunstan > wrote: > On 05/26/2018 03:09 AM, Piotr Stefaniak wrote: >> On 2018-05-26 02:02, Peter Eisentraut wrote: >>> >>> It can be fixed this way: >>> >>> --- a/src/backend/utils/adt/jsonb_util.c >>> +++

Re: why partition pruning doesn't work?

> On 1 June 2018 at 17:53, Tom Lane wrote: > Ashutosh Bapat writes: >> I think the patch is right if we were to handle only SQLValueFunction, >> but the bigger picture here is that we aren't evaluating stable >> functions before run-time partition pruning happens. > > I agree though that it

Re: why partition pruning doesn't work?

> On 3 June 2018 at 19:11, Tom Lane wrote: > Dmitry Dolgov <9erthali...@gmail.com> writes: >> Just to clarify for myself, for evaluating any stable function here would it >> be >> enough to handle all function-like expressions (FuncExpr / OpExpr / >>

Re: why partition pruning doesn't work?

> On 1 June 2018 at 07:19, Pavel Stehule wrote: > > Partition pruning is working now. > > Is it expected? Tested on fresh master. That's interesting. So there are two cases: * vlozeno > (select current_date) (pruning works) * vlozeno > current_date (pruning doesn't work) In

Re: wrong query result with jit_above_cost= 0

> On 26 June 2018 at 20:23, Andres Freund wrote: > Hi, > > On 2018-06-26 23:50:32 +0530, Rushabh Lathia wrote: >> I found the below query which returns the wrong output >> when jit_above_cost= 0 is set. >> >> Steps to reproduce: >> >> CREATE TABLE emp ( >> epno NUMERIC(4), >>

Re: wrong query result with jit_above_cost= 0

> On 26 June 2018 at 22:11, Andres Freund wrote: > On 2018-06-26 22:09:10 +0200, Dmitry Dolgov wrote: >> > On 26 June 2018 at 20:23, Andres Freund wrote: >> > Hi, >> > >> > On 2018-06-26 23:50:32 +0530, Rushabh Lathia wrote: >> >> I found the

Re: wrong query result with jit_above_cost= 0

> On 26 June 2018 at 22:56, Andres Freund wrote: > On 2018-06-26 21:55:07 +0100, Andrew Gierth wrote: >> >>>>> "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes: >> >> Dmitry> Yep, my bad, forgot to turn it on. Now I see what's the

FPW stats?

Hi, Recently I've heard people complaining that Postgres doesn't expose any statistics about how many full page writes happened during some time frame. Indeed, I couldn't find any easy way to do so, and judging from my understanding of xloginsert.c it actually can be done per database with the

Re: FPW stats?

> On 2 May 2018 at 13:10, Michael Paquier <mich...@paquier.xyz> wrote: > On Wed, May 02, 2018 at 12:22:34PM +0200, Dmitry Dolgov wrote: >> Recently I've heard people complaining that Postgres doesn't expose any >> statistics about how many full page writes happened d

Re: pgbench - add \if support

> On 4 January 2018 at 07:32, Fabien COELHO wrote: > > Another rebase to try to please the patch tester. Thanks for working on this. I had just a quick look at it, but I hope I'll have time to post a proper review. In the meantime I'm wondering what am I doing wrong here (I

Re: [HACKERS] [PATCH] Generic type subscripting

> On 7 January 2018 at 23:39, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Dmitry Dolgov <9erthali...@gmail.com> writes: >>> On 4 January 2018 at 03:05, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I wonder what happened to the plan to separate assignment and f

Re: pgbench - add \if support

> On 8 January 2018 at 19:36, Fabien COELHO wrote: > What you are trying to do is the result of combining the pgbench-if patch > and the pgbench-more-ops-and-funcs patch. Oh, I see. I missed the first message about this patch, sorry. But for some reason I can't apply both

Re: [HACKERS] Bug in to_timestamp().

> On 1 February 2018 at 11:24, Arthur Zakirov wrote: > > I fixed those messages, but in a different manner. I think that an > unexpected character is unknown and neither space nor separator. And > better to say that was expected space/separator character. Sounds good,

Write lifetime hints for NVMe

Hi, >From what I see some time ago the write lifetime hints support for NVMe multi streaming was merged into Linux kernel [1]. Theoretically it allows data written together on media so they can be erased together, which minimizes garbage collection, resulting in reduced write amplification as

Re: Write lifetime hints for NVMe

> On 27 January 2018 at 23:53, Tomas Vondra > wrote: > > Amazon actually does provide instance types (f1 and i3) with real NVMe > devices. That's what I'd be testing. Yes, indeed, that's a better target for testing, thanks. I'll write back when will get some

Re: Write lifetime hints for NVMe

> On 27 January 2018 at 16:03, Tomas Vondra > wrote: > > Aren't those numbers far lower that you'd expect from NVMe storage? I do > have a NVMe drive (Intel 750) in my machine, and I can do thousands of > transactions on it with two clients. Seems a bit suspicious.

Re: [HACKERS] Bug in to_timestamp().

> On 12 January 2018 at 13:58, Arthur Zakirov wrote: > > I attached new version of the patch. Now (expected output): > Thanks for working on that! I haven't followed this thread before, and after a quick review I have few side questions. Why not write

Re: [HACKERS] Bug in to_timestamp().

> On 6 February 2018 at 10:17, Arthur Zakirov wrote: > It is strange. I still can apply both v9 [1] and v10 [2] via 'git > apply'. And Patch Tester [3] says that it is applied. But maybe > it is because of my git (git version 2.16.1). > > You can try also 'patch -p1':

Re: JIT compiling with LLVM v10.0

> On 8 February 2018 at 21:26, Thomas Munro <thomas.mu...@enterprisedb.com> > wrote: > On Fri, Feb 9, 2018 at 3:14 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: >> $ ./configure --prefix=/build/postgres-jit/ --with-llvm >> --enable-debug --enable-depe

Re: [HACKERS] Bug in to_timestamp().

> On 7 February 2018 at 22:51, Dmitry Dolgov <9erthali...@gmail.com> wrote: >> On 6 February 2018 at 10:17, Arthur Zakirov <a.zaki...@postgrespro.ru> wrote: >> It is strange. I still can apply both v9 [1] and v10 [2] via 'git >> apply'. And Patch Tester [3] s

Re: [HACKERS] Bug in to_timestamp().

> On 12 February 2018 at 12:49, Arthur Zakirov wrote: > > Yes, I somehow missed it. I changed the behaviour of separator > characters in format string. They are greedy now and eat whitespaces > before a separator character in an input string. I suppose that there >

Re: JIT compiling with LLVM v10.0

> On 8 February 2018 at 10:29, Andreas Karlsson wrote: >> On 02/07/2018 03:54 PM, Andres Freund wrote: >> >> I've pushed v10.0. The big (and pretty painful to make) change is that >> now all the LLVM specific code lives in src/backend/jit/llvm, which is >> built as a shared

Re: [HACKERS] Bug in to_timestamp().

> On 17 February 2018 at 10:02, Arthur Zakirov wrote: > > I think it could be fixed by another patch. But I'm not sure that it > will be accepted as well as this patch :). Why do you think there should be another patch for it?

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

> On 25 December 2017 at 18:40, Tomas Vondra wrote: > The attached v3 fixes this issue, and also a couple of other thinkos Thank you for the patch, it looks quite interesting. After a quick look at it (mostly the first one so far, but I'm going to continue) I have a

Re: Index Skip Scan

> On 18 June 2018 at 19:31, Alexander Korotkov > wrote: >> >> A couple of questions to begin with. >> >> Should the patch continue to "piggy-back" on T_IndexOnlyScan, or should >> a new node (T_IndexSkipScan) be created ? If latter, then there likely >> will be functionality that needs to be

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On Mon, 23 Jul 2018 at 10:38, Ashutosh Bapat > wrote: > > On Fri, Jul 20, 2018 at 3:13 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > > It's of course wrong, it's going to be O(max(m, n)) as you said, but > > the point is still valid - if we

Re: WIP: "More fair" LWLocks

> On Mon, 13 Aug 2018 at 17:36, Alexander Korotkov > wrote: > > Hi! > > I run pgbench (read-write and read-only benchmarks) on Amazon > c5d.18xlarge virtual machine, which has 72 VCPU (approximately same > power as 36 physical cores). The results are attached > (lwlock-fair-ro.png and

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On Fri, 27 Jul 2018 at 20:13, Robert Haas wrote: > > On Fri, Jul 27, 2018 at 3:17 AM, Ashutosh Bapat > wrote: > > Apart from the complexity there's also a possibility that this > > skipping will reduce the efficiency actually in normal cases. Consider > > a case where A and B have exactly

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On Thu, 28 Jun 2018 at 07:54, Amit Langote > wrote: > > On 2018/06/27 22:21, Ashutosh Bapat wrote: > > On Wed, Jun 27, 2018 at 12:28 PM, Amit Langote > >> Ah, okay. I thought of reporting this because I felt the errors may have > >> to do with changes to the related code in HEAD between May

Re: pgbench-ycsb

> On Sat, 21 Jul 2018 at 22:41, Fabien COELHO wrote: > > >> Could you provide a link to the specification? > >> > >> I cannot find something simple, and I was kind of hoping to avoid diving > >> into the source code of the java tool on github:-) In particular, I'm > >> looking for a description

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On Tue, 17 Jul 2018 at 11:58, Ashutosh Bapat > wrote: > > On Sun, Jul 15, 2018 at 11:13 PM, Dmitry Dolgov <9erthali...@gmail.com> wrote: > >> On Thu, 28 Jun 2018 at 07:54, Amit Langote > >> wrote: > >> > >> On 2018/06/27 22:21, Ashutos

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On Thu, 19 Jul 2018 at 21:04, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > > * Just to clarify - the iterating through all the partitions, is it the > > > best > > > way of finding matching ranges? Correct me if I'm wrong, but from wh

Re: LLVM jit and matview

> On Wed, 25 Jul 2018 at 07:49, Michael Paquier wrote: > > On Tue, Jul 24, 2018 at 07:49:56PM -0700, Andres Freund wrote: > > FWIW, this doesn't crash for me, using a trunk checkout for LLVM. I'll > > try older ones, as soon as they finish rebuilding. But perhaps you could > > re-verify that this

Re: WIP: "More fair" LWLocks

> On Mon, 13 Aug 2018 at 17:36, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > > 2) lwlock-far-2.patch > New flag LW_FLAG_FAIR is introduced. This flag is set when first > shared locker in the row releases the lock. When LW_FLAG_FAIR is set > and there is already somebody in the queue,

Re: Commit fest 2018-09

> On Thu, 6 Sep 2018 at 22:50, Michael Paquier wrote: > > If somebody wishes to act as such and is familiar with the community process, > feel free to reply to this thread to manifest yourself. I always wondered what would be the reaction on a first-time CFM? If it's ok I would love to try out,

Re: Index Skip Scan

> On Mon, 18 Jun 2018 at 17:26, Jesper Pedersen > wrote: > > I took Thomas Munro's previous patch [2] on the subject, added a GUC, a > test case, documentation hooks, minor code cleanups, and made the patch > pass an --enable-cassert make check-world run. So, the overall design is > the same.

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On Wed, 29 Aug 2018 at 09:32, Ashutosh Bapat > wrote: > > > * Many functions carry some unrelated arguments just to pass them through, > > which obscures the purpose of a function. > > Can you please provide some examples? E.g this chain with partsupfunc & collations:

Problem with tupdesc in jsonb_to_recordset

Hi, I've found out that currently in some situations jsonb_to_recordset can lead to a crash. Minimal example that I've managed to create looks like this: CREATE OR REPLACE FUNCTION test(data JSONB) RETURNS INTEGER AS $$ DECLARE test_var int; BEGIN WITH jsonb_values

Re: Problem with tupdesc in jsonb_to_recordset

> On Wed, 11 Jul 2018 at 08:27, Michael Paquier wrote: > > On Tue, Jul 10, 2018 at 10:39:28PM +0200, Dmitry Dolgov wrote: > > I've found out that currently in some situations jsonb_to_recordset can > > lead to > > a crash. Minimal example that I've managed to create lo

LLVM jit and matview

Hi, I've found out an interesting problem that you can reproduce by running installcheck against a database with enabled llvm jit (with and without the patch I've sent in [1]): # postgresql.conf jit = on jit_above_cost = 0 jit_optimize_above_cost = 0 jit_inline_above_cost = 0 # matview.sql ...

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On 26 February 2018 at 11:03, Ashutosh Bapat > wrote: > On Fri, Feb 23, 2018 at 7:35 PM, Robert Haas wrote: >> On Fri, Feb 16, 2018 at 12:14 AM, Ashutosh Bapat >> wrote: >>> Appreciate you taking time

Re: typcategory for regconfig

> On 5 April 2018 at 15:27, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dmitry Dolgov <9erthali...@gmail.com> writes: >> Does anyone know, why `typcategory` value for tsvector `regconfig` is >> `TYPCATEGORY_NUMERIC`, > > Because OID is. I think we need all the OID-a

Re: typcategory for regconfig

> On 5 April 2018 at 15:48, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dmitry Dolgov <9erthali...@gmail.com> writes: >> On 5 April 2018 at 15:27, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I think you need to bite the bullet and just provide the flag in >>

typcategory for regconfig

Hi, Does anyone know, why `typcategory` value for tsvector `regconfig` is `TYPCATEGORY_NUMERIC`, but in all the tests it's being used in string format? It's probably not a big deal, but in this thread [1] it prevents me from adopting the nice solution with a boolean flag for `to_tsvector`

Re: json(b)_to_tsvector with numeric values

> On 4 April 2018 at 16:09, Teodor Sigaev wrote: > >>> Hm, seems, it's useful feature, but I suggest to make separate function >>> jsonb_any_to_tsvector and add support for boolean too (if you know better >>> name for function, do not hide it). Changing behavior of existing >>>

Re: json(b)_to_tsvector with numeric values

> On 6 April 2018 at 18:55, Teodor Sigaev <teo...@sigaev.ru> wrote: > > > Dmitry Dolgov wrote: >>> >>> On 6 April 2018 at 16:25, Teodor Sigaev <teo...@sigaev.ru> wrote: >>> 1) I don't like jsonb_all_to_tsvector too.. What if we will accept new >

Re: json(b)_to_tsvector with numeric values

> On 7 April 2018 at 17:09, Teodor Sigaev wrote: >>> See workable sketch for parsing jsonb flags and new worker variant. >> >> >> Yep, thanks for the sketch. Here is the new version of patch, does it look >> close to what you have in mind? > > > Patch looks good except error

Re: json(b)_to_tsvector with numeric values

> On 6 April 2018 at 16:25, Teodor Sigaev wrote: > 1) I don't like jsonb_all_to_tsvector too.. What if we will accept new > variant to index? Let me suggest: > > tsvector jsonb_to_tsvector([regclass,] jsonb, text[]) > > where text[] arg is actually a flags, array contains any

json(b)_to_tsvector with numeric values

Hi, We've just noticed, that current implementation of `json(b)_to_tsvector` can be confusing sometimes, if the target document contains numeric values. In this case we just drop them, and only string values will contribute to the result: select to_tsvector('english', '{"a": "The Fat Rats",

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On 22 March 2018 at 14:18, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> > wrote: > On Thu, Mar 22, 2018 at 4:32 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: >>> On 12 March 2018 at 06:00, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> >

Re: json(b)_to_tsvector with numeric values

> On 2 April 2018 at 11:27, Arthur Zakirov wrote: > On Mon, Apr 02, 2018 at 11:41:12AM +0300, Oleg Bartunov wrote: >> On Mon, Apr 2, 2018 at 9:45 AM, Arthur Zakirov >> wrote: >> I found this bug, when working on presentation about FTS and it

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On 12 March 2018 at 06:00, Ashutosh Bapat > wrote: > Thanks for the note. Here are rebased patches. Since I started to look at this patch, I can share few random notes (although it's not a complete review, I'm in the progress now), maybe it can be helpful. In

jsonb nesting level edge case

Hi, I've just realized, that looks like there is one edge-case in the current jsonb implementation, that can be quite confusing, and I couldn't find any related discussion about it. From what I see there is no limit for how many nested levels can be in a jsonb field, and e.g. when a jsonb is

Re: [HACKERS] Bug in to_timestamp().

> On 18 February 2018 at 18:49, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On 17 February 2018 at 10:02, Arthur Zakirov <a.zaki...@postgrespro.ru> wrote: > > > On Wed, Feb 14, 2018 at 05:23:53PM +0100, Dmitry Dolgov wrote: > > > > > > S

Re: [HACKERS] Bug in to_timestamp().

> On 2 March 2018 at 10:33, Arthur Zakirov wrote: > > The fix you proposed isn't related with the initial report [1] by Amul > Sul, IMHO. The patch tries to fix that behaviour and additionally tries > to be more smart in handling and matching separator characters within

Re: Index Skip Scan

> On Thu, 27 Sep 2018 at 15:59, Jesper Pedersen > wrote: > > I think we need a comment on this in the patch, as 10 * > node->ioss_PlanRows looks a bit random. Yeah, you're right, it's a bit arbitrary number - we just need to make sure that this estimation is not too small (to avoid false

Re: Segfault when creating partition with a primary key and sql_drop trigger exists

> On Wed, 26 Sep 2018 at 05:33, Michael Paquier wrote: > > On Tue, Sep 25, 2018 at 01:39:59PM +0200, Dmitry Dolgov wrote: > > Shouldn't it be fixed by adding EventTriggerAlterTableStart? Judging from > > the > > following call of ATController, we can just pass NUL

Re: [HACKERS] [PATCH] Generic type subscripting

> On Wed, 10 Oct 2018 at 14:26, Pavel Stehule wrote: > > I am playing with this feature little bit Thanks a lot! > I have one idea - can be possible to use integer subscript for record fields? > It can helps with iteration over record. > > example: > > select

Re: Experimenting with hash join prefetch

> On Sun, 14 Oct 2018 at 06:19, Thomas Munro > wrote: > > Cache-oblivious hash joins cause a lot of TLB and cache misses. > ... > (There is another class of cache-aware hash join algorithms that partition > carefully up front to avoid them; that's not us.) Just out of curiosity, can you please

Re: Index Skip Scan

search > from the root of the tree for the next item > the current item. I'm not sure that I understand it correctly, can you elaborate please? From what I see it's quite similar to what's already implemented - we look for a distinct item on the page, and then search the index

Re: Pluggable Storage - Andres's take

> On Fri, 26 Oct 2018 at 13:25, Haribabu Kommi wrote: > > Here I attached the cumulative patch with all fixes that are shared in > earlier mails by me. > Except fast_default test, rest of test failures are fixed. Hi, If I understand correctly, these patches are for the branch

Re: Commitfest 2018-11

> On Thu, 1 Nov 2018 at 14:11, Stephen Frost wrote: > I've added you to the 'cf admins' group Thanks. > so please give it a shot now and let me know if you run into any troubles. Hm...I don't see any difference in CF app, what should be changed?

Re: Commitfest 2018-11

> On Thu, 1 Nov 2018 at 13:05, Daniel Gustafsson wrote: > > Dmitry: Are you still interested in running this commitfest? Yes, I'm still interested. Do I need to have any special permissions in CF app for that (e.g. now I can't "push the button" to start the current one)?

Re: Commitfest 2018-11

> On Thu, 1 Nov 2018 at 15:11, Stephen Frost wrote: > Hmm... Can you try it again? Yep, now I see the administration menu, thanks.

Re: Pluggable Storage - Andres's take

> On Mon, 29 Oct 2018 at 05:56, Haribabu Kommi wrote: > >> This problem couldn't be reproduced on the master branch, so I've tried to >> investigate it. It comes from nodeModifyTable.c:1267, when we've got >> HeapTupleInvisible as a result, and this value in turn comes from >> table_lock_tuple.

Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)

> On Sun, 1 Apr 2018 at 19:58, Yura Sokolov wrote: > > I didn't change serialized format. Therefore is no need to change > SerializeSnapshot. > But in-memory representation were changed, so RestoreSnapshot is changed. This patch went through the last tree commit fests without any noticeable

Re: Optimizing nested ConvertRowtypeExpr execution

> On Mon, 9 Apr 2018 at 14:16, Ashutosh Bapat > wrote: > > On Mon, Apr 9, 2018 at 5:34 PM, Kyotaro HORIGUCHI > wrote: > > > > The new code doesn't seem to work as written. > > > >> arg = eval_const_expressions_mutator((Node *) cre->arg, > >>context); >

Re: Optimizing nested ConvertRowtypeExpr execution

> On Sun, 4 Nov 2018 at 15:48, Andrew Gierth > wrote: > > >>>>> "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes: > > Dmitry> This patch went through the last tree commit fests without any > Dmitry> noticeable activity, but cf

Re: using index or check in ALTER TABLE SET NOT NULL

>On Sun, 15 Apr 2018 at 09:09, Sergei Kornilov wrote: > > Attached updated patch follows recent Reorganize partitioning code commit. > regards, Sergei This patch went through the last tree commit fests without any noticeable activity, but cfbot says it still applies and doesn't break any tests.

Re: Flexible permissions for REFRESH MATERIALIZED VIEW

> On Mon, 21 May 2018 at 15:46, Robert Haas wrote: > > On Sat, May 19, 2018 at 12:59 PM, Greg Stark wrote: > > On 19 May 2018 at 01:13, Stephen Frost wrote: > >> I'm not entirely sure about the varlena suggestion, seems like that > >> would change a great deal more code and be slower, though

Re: CF app feature request

On Fri, 2 Nov 2018 at 10:24, Fabien COELHO wrote: > > > Bonjour Michaël, > > >> Because the same patch submission is already counted? It is a rare > >> occurence, so just a "Withdrawn" state could be enough, and slightly false > >> CF stats are no big deal. > > > > Or as we are dealing with

Re: [HACKERS] [PATCH] Generic type subscripting

> On Wed, 7 Nov 2018 at 17:09, Pavel Stehule wrote: > > I don't agree. If we use a same syntax for some objects types, we should to > enforce some consistency. Just to make it clear, consistency between what? > I don't think so you should to introduce nulls for JSONs. In this case, the >

Re: [Bug Fix]ECPG: cancellation of significant digits on ECPG

> On Thu, 17 May 2018 at 06:10, Higuchi, Daisuke > wrote: > > Currently our customer uses PostgreSQL 9.6 and hits ECPG's bug during using > numeric data type by SQLDA. > I confirmed that this problem is occurred on master and 9.6 latest branch. > > FIX > ---

Re: [HACKERS] [PATCH] Generic type subscripting

> On Thu, 8 Nov 2018 at 06:14, Pavel Stehule wrote: > >> Now it's my turn to disagree. As an argument I have this thread [1], where >> similar discussion happened about flexibility of jsonb and throwing an errors >> (in this particular case whether or not to throw an error when a non existing >>

Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA

> On Mon, 2 Jul 2018 at 15:54, Jesper Pedersen > wrote: > > The patch from November 27, 2017 still applies (with hunks), > > https://commitfest.postgresql.org/18/1166/ > > passes "make check-world" and shows performance improvements. > > Keeping it in "Ready for Committer". Looks like for

Re: using index or check in ALTER TABLE SET NOT NULL

> On Sun, 4 Nov 2018 at 19:03, Sergei Kornilov wrote: > > > If not properly cataloguing NOT NULL constraints would be fixed, can it > > potentially conflict with the current patch or not? > We already doing same stuff for "alter table attach partition" and in this > patch i use exactly this

Re: Index Skip Scan

> On Mon, 12 Nov 2018 at 13:29, Sergei Kornilov wrote: > > I found reproducible crash due assert failure: FailedAssertion("!(numCols > > 0)", File: "pathnode.c", Line: 2795) > > create table tablename (i int primary key); > > select distinct i from tablename where i = 1; > Query is obviously

Re: Range phrase operator in tsquery

> On Fri, 27 Apr 2018 at 13:03, Aleksandr Parfenov > wrote: > > Nowadays, phrase operator in Postgres FTS supports only exact match of > the distance between two words. It is sufficient for a search of > simple/exact phrases, but in some cases exact distance is unknown and we > want to words be

Re: [Bug Fix]ECPG: cancellation of significant digits on ECPG

> On Tue, 6 Nov 2018 at 10:19, Higuchi, Daisuke > wrote: > > Thank you for checking! > I rebased patches on the current master, so I attach them. After adding 'EXEC SQL ALLOCATE DESCRIPTOR sqlda' I've managed to reproduce the problem you're talking about, and indeed it looks strange: =# table

Re: [HACKERS] [PATCH] Generic type subscripting

> On Fri, 12 Oct 2018 at 07:52, Pavel Stehule wrote: > >> > postgres=# insert into test(v) values( '[]'); >> > INSERT 0 1 >> > postgres=# update test set v[1000] = 'a'; >> > UPDATE 1 >> > postgres=# update test set v[1000] = 'a'; >> > UPDATE 1 >> > postgres=# update test set v[1000] = 'a'; >> >

Re: Refactoring the checkpointer's fsync request queue

> On Wed, 14 Nov 2018 at 00:44, Thomas Munro > wrote: > > Here is a rebased version of the patch, post pread()/pwrite(). I have > also rewritten the commit message to try to explain the rationale > concisely, instead of requiring the reader to consult multiple > discussions that jump between

Re: Make description of heap records more talkative for flags

> On Fri, 15 Jun 2018 at 17:09, Nathan Bossart wrote: > > 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 > > -

Re: Index Skip Scan

> On Mon, 12 Nov 2018 at 13:55, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Mon, 12 Nov 2018 at 13:29, Sergei Kornilov wrote: > > > > I found reproducible crash due assert failure: FailedAssertion("!(numCols > > > 0)", File: "pathno

Re: Add function to release an allocated SQLDA

> On Wed, 13 Jun 2018 at 06:30, Kato, Sho wrote: > > I add a function called ECPGfreeSQLDA() becasue there is no API for releasing > the SQLDA stored the result set. > > On Mon, 18 Jun 2018 at 07:42, Thomas Munro > wrote: > > I wonder how other ESQL/C implementations deal with this stuff (...)

Re: Segfault when creating partition with a primary key and sql_drop trigger exists

> On Wed, 3 Oct 2018 at 09:53, Michael Paquier wrote: > > On Fri, Sep 28, 2018 at 12:17:00PM +0900, Michael Paquier wrote: > > I think that Alvaro should definitely look at this patch to be sure, or > > I could do it, but I would need to spend way more time on this and check > > event trigger

Re: Index Skip Scan

> On Tue, 9 Oct 2018 at 15:43, Pavel Stehule wrote: > > Hi > > I tested last patch and I have some notes: > > 1. > > postgres=# explain select distinct a1 from foo; > +---+ > |

Re: Index Skip Scan

> On Tue, 9 Oct 2018 at 18:13, Pavel Stehule wrote: > >> It looks like good idea, but then the node should be named "index scan" and >> other info can be displayed in detail parts. It can be similar like "sort". >> The combination of unique and index skip scan looks strange :) > > maybe we don't

Re: Segfault when creating partition with a primary key and sql_drop trigger exists

> On Mon, 24 Sep 2018 at 17:58, Alvaro Herrera wrote: > > On 2018-Sep-20, Marco Slot wrote: > > > We're seeing a segmentation fault when creating a partition of a > > partitioned table with a primary key when there is a sql_drop trigger on > > Postgres 11beta4. > > > > We discovered it because

Re: New GUC to sample log queries

> On Sun, 18 Nov 2018 at 10:52, Adrien Nayrat > wrote: > > For me, the question is how to name this GUC? Is "log_sample_rate" is enough? > I am not sure because it is only related to queries logged by > log_min_duration_statements. Since it's hard to come up with a concise name that will mention

Re: using index or check in ALTER TABLE SET NOT NULL

> On Thu, Nov 22, 2018 at 6:04 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > Absolutely agree. Looking at the history of the patch I see that it went > through some extensive review and even was marked as Ready for Committer > before > the commentary from Peter, but

  1   2   3   4   5   6   >