Re: [PATCH v20] GSSAPI encryption support

On 2019-04-09 04:51, Stephen Frost wrote: >> Running just 002_enc.pl by itself passes the tests! > Great! I think what I'll do is work to incorporate the two tests back > into one script, to avoid whatever the race condition or other confusion > is happening on macOS here. That seems reasonable.

Re: [PATCH v20] GSSAPI encryption support

On 2019-04-09 06:11, Tom Lane wrote: > I tried to replicate this on my own laptop (macOS 10.14.4 ... I do not > think there is or ever will be a 10.14.14). right > kerberos test fails immediately: > > 1..4 > # setting up Kerberos > # Running: krb5-config --version > # Running: kdb5_util create -

RE: Problem with default partition pruning

Horiguchi-san, Thanks for your comments. > -Original Message- > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > Sent: Tuesday, April 09, 2019 10:33 AM > To: hosoya.yuz...@lab.ntt.co.jp > Cc: langote_amit...@lab.ntt.co.jp; thibaut.madela...@dalibo.com; > imai.yoshik...@

Re: MSVC Build support with visual studio 2019

On Wed, Mar 27, 2019 at 11:42 AM Haribabu Kommi wrote: > > On Wed, Mar 27, 2019 at 3:03 AM Andrew Dunstan < > andrew.duns...@2ndquadrant.com> wrote: > >> >> On 3/20/19 8:36 PM, Haribabu Kommi wrote: >> > Hi Hackers, >> > >> > Here I attached a patch that supports building of PostgreSQL with VS >>

Re: Problem with default partition pruning

Hi. At Tue, 9 Apr 2019 16:41:47 +0900, "Yuzuko Hosoya" wrote in <00cf01d4eea7$afa43370$0eec9a50$@lab.ntt.co.jp> > > So still it is wrong that the new code is added at the beginning of the > > loop on clauses in > > gen_partprune_steps_internal. > > > > > If partq

Re: Problem with default partition pruning

At Tue, 09 Apr 2019 17:37:25 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190409.173725.31175835.horiguchi.kyot...@lab.ntt.co.jp> > > I'm attaching the latest version. Could you please check it again? By the way, I noticed that partition constraint in a multi-level partition cont

Re: Problem with default partition pruning

Horiguchi-san, On 2019/04/09 17:51, Kyotaro HORIGUCHI wrote: > At Tue, 09 Apr 2019 17:37:25 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20190409.173725.31175835.horiguchi.kyot...@lab.ntt.co.jp> >>> I'm attaching the latest version. Could you please check it again? > > By the

Re: Status of the table access method work

> On Tue, Apr 9, 2019 at 4:12 AM Haribabu Kommi > wrote: > > On Sat, Apr 6, 2019 at 7:25 AM Andres Freund wrote: >> >> With regards to storing the rows themselves, the second biggest >> limitation is a limitation that is not actually a part of tableam >> itself: WAL. Many tableam's would want to

more isolation tests for update tuple routing

Continuing the discussion at: https://www.postgresql.org/message-id/26571.1554741097%40sss.pgh.pa.us Tom wrote: > It struck me just as I was pushing it that this test doesn't exercise > EPQ with any of the interesting cases for partition routing (ie where > the update causes a move to a different

PGCOLOR? (Re: pgsql: Unified logging system for command-line programs)

Re: Peter Eisentraut 2019-04-01 > - Some color in the messages, similar to gcc and clang. Set > PG_COLOR=auto to try it out. Some colors are predefined, but can be > customized by setting PG_COLORS. Can we rename PG_COLOR to PGCOLOR? This is the only PG* environment variable prefixed with t

Re: Status of the table access method work

On Tue, Apr 9, 2019 at 2:12 PM Haribabu Kommi wrote: > I got the same doubt when i looked into some of the UNDO patches > where it tries to modify the core code to add UNDO specific WAL types. > Different AM's may need different set of operations to be WAL logged, > so it may be better for the AM'

Re: Problem with default partition pruning

Hi, Amit. Thank you for the explanation. At Tue, 9 Apr 2019 18:09:20 +0900, Amit Langote wrote in <4c1074cc-bf60-1610-c728-9a5b12f5b...@lab.ntt.co.jp> > > The partition constraint is equivalent to "(a IS NOT NULL) AND (a > >> = 2) AND (a < 4)". Is it intentional (for, for example, > > performanc

Re: libpq debug log

Hello. Thank you for the new patch. At Tue, 9 Apr 2019 06:19:32 +, "Iwata, Aya" wrote in <71E660EB361DF14299875B198D4CE5423DF161BA@g01jpexmbkw25> > Hi, > > I update patch to improve PQtrace(); output log message in one line. > Please find my attached patch. > > How it changed: > > > The ba

Re: dropdb --force

Is this the intended behavior? SIGTERM is received. test=# begin; BEGIN test=# create table test(a int); CREATE TABLE In another terminal drop the database. test=# begin; psql: FATAL: terminating connection due to administrator command server closed the connection unexpectedly This pro

Re: dropdb --force

Yes, I think it is because of this code Snippet if (force_terminate) { /* try to terminate backend */ #ifdef HAVE_SETSID kill(-(proc->pid), SIGTERM); #else kill(proc->pid, SIGTER

Re: PGCOLOR? (Re: pgsql: Unified logging system for command-line programs)

On 2019-04-09 11:22, Christoph Berg wrote: > Can we rename PG_COLOR to PGCOLOR? This is the only PG* environment > variable prefixed with the extra underscore, and remembering that will > be confusing. (Like pgbench should really be named pg_bench for > consistency.) Even if it's not a libpq variab

Re: dropdb --force

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested The feature works fine on my machine. The code is well-written.

Re: pgsql: Unified logging system for command-line programs

Re: Peter Eisentraut 2019-04-01 > - There is support for setting a "log level". This is not meant to be > user-facing, but can be used internally to implement debug or > verbose modes. I'm not entirely sure what happened here, but I think this made pg_restore verbose by default (and there is

Re: PGCOLOR? (Re: pgsql: Unified logging system for command-line programs)

Re: Peter Eisentraut 2019-04-09 > I'm okay with changing it. As you indicate, I chose the name so that it > doesn't look like a libpq variable. There are some other PG_ variables > throughout the code, but those appear to be mostly for internal use. > Also, there is GCC_COLORS, LS_COLORS, etc.

Re: Status of the table access method work

Hi, On 2019-04-09 11:17:29 +0200, Dmitry Dolgov wrote: > I'm also curious about that. As far as I can see the main objection against > that was that in this case the recovery process will depend on an extension, > which could violate reliability. I don't think that's a primary concern - although

Re: COLLATE: Hash partition vs UPDATE

Hi Amit, On 4/8/19 11:18 PM, Amit Langote wrote: As of this commit, hashing functions hashtext() and hashtextextended() require a valid collation to be passed in. ISTM, satisfies_hash_partition() that's called by hash partition constraint checking should have been changed to use FunctionCall2Co

Re: [HACKERS] Cached plans and statement generalization

New version of the patching disabling autoprepare for rules and handling planner error. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/autoprepare.sgml b/doc/src/sgml/autoprepare.sgml new file mode 100644 index 00

Re: COLLATE: Hash partition vs UPDATE

On Tue, Apr 9, 2019 at 9:44 PM Jesper Pedersen wrote: > > Hi Amit, > > On 4/8/19 11:18 PM, Amit Langote wrote: > > As of this commit, hashing functions hashtext() and hashtextextended() > > require a valid collation to be passed in. ISTM, > > satisfies_hash_partition() that's called by hash parti

Re: proposal: plpgsql pragma statement

Hi Pavel, On 3/25/19 3:50 AM, Pavel Stehule wrote: > po 25. 3. 2019 v 8:38 odesílatel David Steele > napsal: > > On 3/10/19 8:39 PM, Pavel Stehule wrote: > >     Here is pragma patch with demo > We're still not getting real review for this patch and Andrew

Re: Pluggable Storage - Andres's take

On 08/04/2019 20:37, Andres Freund wrote: On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote: There's a little bug in index-only scan executor node, where it mixes up the slots to hold a tuple from the index, and from the table. That doesn't cause any ill effects if the AM uses TTSOpsHeapTup

GSOC 2019 proposal 'WAL-G safety features'

Dear PostgreSQL community, I am a GSoC 2019 applicant and am working on 'WAL-G safety features'. I have finished an initial draft of my proposal and I would appreciate your comments and advice on my proposal. I know it is pretty late for the improvement of my proposal, but I will be glad to join i

Re: pg_dump is broken for partition tablespaces

On 2019-Mar-06, Andres Freund wrote: > > I also find it far from clear that: > > > > > > The tablespace_name is > > the name > > of the tablespace in which the new table is to be created. > > If not specified, > >is consulted, or > >if the table is te

Re: Zedstore - compressed in-core columnar storage

Hi, On 09.04.2019 3:27, Ashwin Agrawal wrote: Heikki and I have been hacking recently for few weeks to implement in-core columnar storage for PostgreSQL. Here's the design and initial implementation of Zedstore, compressed in-core columnar storage (table access method). Attaching the patch and l

Re: Zedstore - compressed in-core columnar storage

On 09.04.2019 17:09, Konstantin Knizhnik wrote: Hi, On 09.04.2019 3:27, Ashwin Agrawal wrote: Heikki and I have been hacking recently for few weeks to implement in-core columnar storage for PostgreSQL. Here's the design and initial implementation of Zedstore, compressed in-core columnar stora

Re: shared-memory based stats collector

On Thu, Apr 04, 2019 at 09:25:12AM +0900, Kyotaro HORIGUCHI wrote: Hello. At Wed, 3 Apr 2019 12:56:59 -0700, Andres Freund wrote in <20190403195659.fcmk2i7ruxhty...@alap3.anarazel.de> Unfortunately I don't think it's realistic to target this to v12. I think it was unlikely to make at the begi

Re: Zedstore - compressed in-core columnar storage

On 09/04/2019 18:00, Konstantin Knizhnik wrote: On 09.04.2019 17:09, Konstantin Knizhnik wrote: standard Postgres heap and my VOPS extension. As test data I used TPC-H benchmark (actually only one lineitem table generated with tpch-dbgen utility with scale factor 10 (~8Gb database). I attached s

Re: POC: GROUP BY optimization

On Thu, Apr 04, 2019 at 05:11:09PM +0200, Dmitry Dolgov wrote: On Thu, Jan 31, 2019 at 12:24 PM Andres Freund wrote: As nothing has happened since, I'm marking this as returned with feedback. This patch was on my radar for some time in the past and we've seen use cases where it could be prett

Re: [PATCH v20] GSSAPI encryption support

On Wed, Apr 3, 2019 at 08:49:25AM +0200, Magnus Hagander wrote: > On Wed, Apr 3, 2019 at 12:22 AM Joe Conway wrote: > Personally I don't find it as confusing as is either, and I find hostgss > to be a good analog of hostssl. On the other hand hostgssenc is long and > unintuitive. So +

Re: more isolation tests for update tuple routing

Amit Langote writes: > Per what Andres mentioned in his reply on the original thread [1], in > scenarios 1 and 2 where the 1st session's update causes a row to move, > session 2 produces the following error when trying to update the same row: > ERROR: tuple to be locked was already moved to anoth

Re: Zedstore - compressed in-core columnar storage

On 09.04.2019 18:08, Heikki Linnakangas wrote: On 09/04/2019 18:00, Konstantin Knizhnik wrote: On 09.04.2019 17:09, Konstantin Knizhnik wrote: standard Postgres heap and my VOPS extension. As test data I used TPC-H benchmark (actually only one lineitem table generated with tpch-dbgen utility

block-level incremental backup

Hi, Several companies, including EnterpriseDB, NTT, and Postgres Pro, have developed technology that permits a block-level incremental backup to be taken from a PostgreSQL server. I believe the idea in all of those cases is that non-relation files should be backed up in their entirety, but for re

Re: Zedstore - compressed in-core columnar storage

On 2019-Apr-09, Konstantin Knizhnik wrote: > On 09.04.2019 3:27, Ashwin Agrawal wrote: > > Heikki and I have been hacking recently for few weeks to implement > > in-core columnar storage for PostgreSQL. Here's the design and initial > > implementation of Zedstore, compressed in-core columnar stora

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Tue, Apr 09, 2019 at 11:29:18AM +0900, Michael Paquier wrote: On Sat, Mar 30, 2019 at 09:13:01PM +0100, Tomas Vondra wrote: Hmmm, what's the right status in the CF app when a part of a patch was committed and the rest should be moved to the next CF? Committed, Moved to next CF, or something e

Re: Failure in contrib test _int on loach

05.04.2019 19:41, Anastasia Lubennikova writes: 05.04.2019 18:01, Tom Lane writes: Andrew Dunstan writes: On Fri, Apr 5, 2019 at 2:02 AM Thomas Munro wrote: This is a strange failure: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=loach&dt=2019-04-05%2005%3A15%3A00 [ wrong answe

Re: Zedstore - compressed in-core columnar storage

On 09.04.2019 18:51, Alvaro Herrera wrote: On 2019-Apr-09, Konstantin Knizhnik wrote: On 09.04.2019 3:27, Ashwin Agrawal wrote: Heikki and I have been hacking recently for few weeks to implement in-core columnar storage for PostgreSQL. Here's the design and initial implementation of Zedstor

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 2019-Mar-27, Tomas Vondra wrote: > Attached are the remaining parts of this patch series - the multivariate > histograms, and also a new patch tweaking regression tests for the old > statistic types (ndistinct, dependencies) to adopt the function-based > approach instead of the regular EXPLAIN.

Re: jsonpath

On Sun, Apr 07, 2019 at 03:03:58AM +0300, Alexander Korotkov wrote: On Sun, Apr 7, 2019 at 2:37 AM Tom Lane wrote: Alexander Korotkov writes: > Thus, contents of unused function makes test fail or pass. So far, it > looks like a compiler bug. Any thoughts? Yeah :-(. The fact that we've not

Re: Zedstore - compressed in-core columnar storage

On 09/04/2019 18:00, Konstantin Knizhnik wrote: Looks like the original problem was caused by internal postgres compressor: I have not configured Postgres to use lz4. When I configured Postgres --with-lz4, data was correctly inserted in zedstore table, but looks it is not compressed at all: post

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Tue, Apr 09, 2019 at 12:14:47PM -0400, Alvaro Herrera wrote: On 2019-Mar-27, Tomas Vondra wrote: Attached are the remaining parts of this patch series - the multivariate histograms, and also a new patch tweaking regression tests for the old statistic types (ndistinct, dependencies) to adopt

Possibly-crazy idea for getting rid of some user confusion

I've lost count of the number of gripes I've seen where somebody tried to write something like "SELECT TIMESTAMP something", modeling this on what you can do if the something is a literal constant, but it didn't work because they were working with client infrastructure that put a $n parameter symbo

Re: block-level incremental backup

Hello, On 09.04.2019 18:48, Robert Haas wrote: - It would also be nice if pg_basebackup could write backups to places other than the local disk, like an object store, a tape drive, etc. But that also sounds like a separate effort. Thoughts? (Just thinking out loud) Also it might be useful to

Re: block-level incremental backup

Hi, On 2019-04-09 11:48:38 -0400, Robert Haas wrote: > 2. When you use pg_basebackup in this way, each relation file that is > not sent in its entirety is replaced by a file with a different name. > For example, instead of base/16384/16417, you might get > base/16384/partial.16417 or however we de

Re: jsonpath

On Tue, Apr 9, 2019 at 12:16 PM Tomas Vondra wrote: > > Have you tried other compiler version / different optimization level? Or > running it under valgrind. Not sure how difficult that is on Windows. > > It's not possible AFAIK. I will look at different compilers when I am back local to the mac

Re: Minimal logical decoding on standbys

On Sat, 6 Apr 2019 at 04:45, Andres Freund wrote: > > Hi, > > Thanks for the new version of the patch. Btw, could you add Craig as a > co-author in the commit message of the next version of the patch? Don't > want to forget him. I had put his name in the earlier patch. But now I have made it eas

Re: Zedstore - compressed in-core columnar storage

On 09.04.2019 19:19, Heikki Linnakangas wrote: On 09/04/2019 18:00, Konstantin Knizhnik wrote: Looks like the original problem was caused by internal postgres compressor: I have not configured Postgres to use lz4. When I configured Postgres --with-lz4, data was correctly inserted in zedstore

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Tue, Apr 9, 2019 at 1:07 PM Kyotaro HORIGUCHI wrote: > > Hello. > > At Mon, 8 Apr 2019 19:22:04 +0900, Fujii Masao wrote > in > > > "TRUNCATE" option for vacuum command should be added to the open items? > > > > Yes, I think. > > Attached is the patch which adds TRUNCATE option into VACUUM.

Re: Compressed TOAST Slicing

Hi! > 12 марта 2019 г., в 10:22, Andrey Borodin написал(а): > > 3. And I'd use memmove despite the comment why we do not do that. It is > SSE-optimized and cache-optimized nowadays. So, I've pushed idea a little bit and showed that decompress byte-copy cycle to Vladimir Leskov. while (len--)

Re: Copy function for logical replication slots

On 2019-Apr-05, Petr Jelinek wrote: > On 05/04/2019 23:16, Alvaro Herrera wrote: > > The mechanism of creating a new slot from the source, then later > > advancing the LSN of the new slot using the updated values from the > > source slot, seems quite clever. I reworded the comment that explained

Re: Compressed TOAST Slicing

> On Apr 9, 2019, at 10:09 AM, Andrey Borodin wrote: > > He advised me to use algorithm that splits copied regions into smaller > non-overlapping subregions with exponentially increasing size. > > while (off <= len) > { >memcpy(dp, dp - off, off); >len -= off; >dp += off; >off

Re: Compressed TOAST Slicing

> 9 апр. 2019 г., в 22:12, Paul Ramsey написал(а): > > Wow, well beyond slicing, just being able to decompress 25% faster is a win > for pretty much any TOAST use case. I guess the $100 question is: > portability? The whole reason for the old-skool code that’s there now was > concerns about

Re: Compressed TOAST Slicing

On 2019-04-09 10:12:56 -0700, Paul Ramsey wrote: > > > On Apr 9, 2019, at 10:09 AM, Andrey Borodin wrote: > > > > He advised me to use algorithm that splits copied regions into smaller > > non-overlapping subregions with exponentially increasing size. > > > > while (off <= len) > > { > >me

Re: Compressed TOAST Slicing

> 9 апр. 2019 г., в 22:20, Andres Freund написал(а): > > Just use memmove? It's usually as fast these days. No, unfortunately, it is fixing things incompatible way. In pglz side-effects of overlapping addresses are necessary, not the way memmove avoids it. I.e. bytes 01234 ^ copy here thre

Re: Compressed TOAST Slicing

Andres Freund writes: > On 2019-04-09 10:12:56 -0700, Paul Ramsey wrote: >> Wow, well beyond slicing, just being able to decompress 25% faster is a win >> for pretty much any TOAST use case. I guess the $100 question is: >> portability? The whole reason for the old-skool code that’s there now wa

Re: [PATCH v20] GSSAPI encryption support

Bruce Momjian writes: > On Wed, Apr 3, 2019 at 08:49:25AM +0200, Magnus Hagander wrote: >> On Wed, Apr 3, 2019 at 12:22 AM Joe Conway wrote: >> >> Personally I don't find it as confusing as is either, and I find >> hostgss to be a good analog of hostssl. On the other hand hostgssenc >> is long

Re: block-level incremental backup

Having worked in the data storage industry since the '80s, I think backup is an important capability. Having said that, the ideas should be expanded to an overall data management strategy combining local and remote storage including cloud. >From my experience, record and transaction consistency is

Re: block-level incremental backup

On Tue, Apr 9, 2019 at 12:35 PM Andres Freund wrote: > Hm. But that means that files that are shipped nearly in their entirety, > need to be fully rewritten. Wonder if it's better to ship them as files > with holes, and have the metadata in a separate file. That'd then allow > to just fill in the

Re: block-level incremental backup

On Tue, Apr 9, 2019 at 12:32 PM Arthur Zakirov wrote: > In pg_probackup we have remote restore via SSH in the beta state. But > SSH isn't an option for in-core approach I think. That's a little off-topic for this thread, but I think we should have some kind of extensible mechanism for pg_baseback

Re: Zedstore - compressed in-core columnar storage

On Tue, Apr 9, 2019 at 11:51 AM Alvaro Herrera wrote: > This is not surprising, considering that columnar store is precisely the > reason for starting the work on table AMs. > > We should certainly look into integrating some sort of columnar storage > in mainline. Not sure which of zedstore or VO

Re: PageGetFreeSpace() isn't quite the right thing for some of its callers

On Mon, Apr 8, 2019 at 5:15 PM Peter Geoghegan wrote: > On Mon, Apr 8, 2019 at 2:10 PM Andres Freund wrote: > > I'm not sure I understand what the problem is. We got to get the > > information for the fsm from somewhere? Are you arguing we should > > instead have it included as an explicit xlog r

Re: proposal: plpgsql pragma statement

Hi út 9. 4. 2019 v 15:03 odesílatel David Steele napsal: > Hi Pavel, > > On 3/25/19 3:50 AM, Pavel Stehule wrote: > > po 25. 3. 2019 v 8:38 odesílatel David Steele > > napsal: > > > > On 3/10/19 8:39 PM, Pavel Stehule wrote: > > > Here is pragma patch wit

Dependences records and comments

Hi, hackers!When we create/alter object we already add dependency row to pg_depend (or, pg_shdepend) table for object that is depends (e.g. trigger depends on table which it created).But when I add comment on table, no one dependency row is added. Why?

Re: Early WIP/PoC for inlining CTEs

I wrote: > Andrew Gierth writes: >> So what I think we need to do here is to forbid inlining if (a) the >> refcount is greater than 1 and (b) the CTE in question contains, >> recursively anywhere inside its rtable or the rtables of any of its >> nested CTEs, a "self_reference" RTE. > That's kind

Re: Zedstore - compressed in-core columnar storage

On Tue, Apr 9, 2019 at 11:29 AM Robert Haas wrote: > On Tue, Apr 9, 2019 at 11:51 AM Alvaro Herrera > wrote: > > This is not surprising, considering that columnar store is precisely the > > reason for starting the work on table AMs. > > > > We should certainly look into integrating some sort of

Re: pg_dump is broken for partition tablespaces

On 2019-Mar-07, David Rowley wrote: > On Thu, 7 Mar 2019 at 11:37, Andres Freund wrote: > > > > On 2019-03-07 11:31:15 +1300, David Rowley wrote: > > > Do you think it's fine to reword the docs to make this point more > > > clear, or do you see this as a fundamental problem with the patch? > > >

Re: PageGetFreeSpace() isn't quite the right thing for some of its callers

On Tue, Apr 9, 2019 at 11:35 AM Robert Haas wrote: > Maybe we should rename it. There are only about 20 PageGetFreeSpace() callers, so that shouldn't be too disruptive. We might also need to rename PageGetFreeSpaceForMultipleTuples() and PageGetExactFreeSpace(). And, heapam.c won't be able to cal

Re: Zedstore - compressed in-core columnar storage

On Tue, Apr 9, 2019 at 9:13 AM Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > > On 09.04.2019 18:51, Alvaro Herrera wrote: > > On 2019-Apr-09, Konstantin Knizhnik wrote: > > > >> On 09.04.2019 3:27, Ashwin Agrawal wrote: > >>> Heikki and I have been hacking recently for few weeks to i

Re: block-level incremental backup

On 2019-04-09 17:48, Robert Haas wrote: > It will > probably be more efficient in many cases to instead scan all the WAL > generated since that LSN and extract block references from it, but > that is only possible if the server has all of that WAL available or > can somehow get it from the archive.

Re: Zedstore - compressed in-core columnar storage

On 09/04/2019 23:24, Ashwin Agrawal wrote: BTW, can I express a small measure of disappointment that the name for the thing under discussion on this thread chose to be called "zedstore"?  That seems to invite confusion with "zheap", especially in parts of the world where the last

Re: Zedstore - compressed in-core columnar storage

C-Tree? Peter Geoghegan (Sent from my phone)

Re: [survey] New "Stable" QueryId based on normalized query text

On Wed, Mar 20, 2019 at 03:19:58PM -0700, legrand legrand wrote: > > The rest of thread raise quite a lot of concerns about the semantics, > > the cost and the correctness of this patch. After 5 minutes checking, > > it wouldn't suits your need if you use custom functions, custom types, > > custom

Re: block-level incremental backup

On 2019-Apr-09, Peter Eisentraut wrote: > On 2019-04-09 17:48, Robert Haas wrote: > > 3. There should be a new tool that knows how to merge a full backup > > with any number of incremental backups and produce a complete data > > directory with no remaining partial files. > > Are there by any cha

Re: pg_dump is broken for partition tablespaces

On 2019-Apr-09, Alvaro Herrera wrote: > However, in order to fix the pg_dump behavior for the partitioned rel, > we would need to emit the tablespace differently, i.e. not use SET > default_tablespace, but instead attach the tablespace clause to the > CREATE TABLE line. > > I'll go have a look at

Re: pg_dump is broken for partition tablespaces

On 2019-Mar-06, Andres Freund wrote: > I don't think the argument that the user intended to explicitly set a > tablespace holds much water if it was just set via default_tablespace, > rather than an explicit TABLESPACE. I think iff you really want > something like this feature, you'd have to mark

Re: pg_dump is broken for partition tablespaces

On 2019-Apr-09, Alvaro Herrera wrote: > There is one deficiency that needs to be solved in order for this to > work fully: currently there is no way to reset "reltablespace" to 0. Therefore I propose to add ALTER TABLE tb ... RESET TABLESPACE; which sets reltablespace to 0, and it would work only

Re: more isolation tests for update tuple routing

On 2019/04/10 0:45, Tom Lane wrote: > Amit Langote writes: >> Per what Andres mentioned in his reply on the original thread [1], in >> scenarios 1 and 2 where the 1st session's update causes a row to move, >> session 2 produces the following error when trying to update the same row: >> ERROR: tup

Re: shared-memory based stats collector

At Tue, 9 Apr 2019 17:03:33 +0200, Tomas Vondra wrote in <20190409150333.5iashyjxm5jmraml@development> > Unfortunately, now that we're past code freeze it's clear this is a > PG12 > matter now :-( > > I personally consider this to be very worthwhile & beneficial > improvement, > but I agree with

Re: Problem with default partition pruning

Horiguchi-san, On 2019/04/09 18:49, Kyotaro HORIGUCHI wrote: > Hi, Amit. Thank you for the explanation. > > At Tue, 9 Apr 2019 18:09:20 +0900, Amit Langote > wrote in > <4c1074cc-bf60-1610-c728-9a5b12f5b...@lab.ntt.co.jp> >>> The partition constraint is equivalent to "(a IS NOT NULL) AND (a >>

Re: Possibly-crazy idea for getting rid of some user confusion

At Tue, 09 Apr 2019 12:28:16 -0400, Tom Lane wrote in <19970.1554827...@sss.pgh.pa.us> > I've lost count of the number of gripes I've seen where somebody > tried to write something like "SELECT TIMESTAMP something", modeling > this on what you can do if the something is a literal constant, but >

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

At Wed, 10 Apr 2019 02:00:03 +0900, Fujii Masao wrote in > On Tue, Apr 9, 2019 at 1:07 PM Kyotaro HORIGUCHI > wrote: > > > > Hello. > > > > At Mon, 8 Apr 2019 19:22:04 +0900, Fujii Masao > > wrote in > > > > > > "TRUNCATE" option for vacuum command should be added to the open items? > > > >

Re: Problem with default partition pruning

On 2019/04/09 17:37, Kyotaro HORIGUCHI wrote: > At Tue, 9 Apr 2019 16:41:47 +0900, "Yuzuko Hosoya" > wrote >>> So still it is wrong that the new code is added at the beginning of the >>> loop on clauses in >>> gen_partprune_steps_internal. >>> If partqual resul

Re: Problem with default partition pruning

Horiguchi-san, > -Original Message- > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > Sent: Tuesday, April 09, 2019 5:37 PM > To: hosoya.yuz...@lab.ntt.co.jp > Cc: langote_amit...@lab.ntt.co.jp; thibaut.madela...@dalibo.com; > imai.yoshik...@jp.fujitsu.com; pgsql-hacker

Re: pgsql: tableam: basic documentation.

Hi Andres, On Thu, Apr 04, 2019 at 12:42:06AM +, Andres Freund wrote: > tableam: basic documentation. > > This adds documentation about the user oriented parts of table access > methods (i.e. the default_table_access_method GUC and the USING clause > for CREATE TABLE etc), adds a basic chapte

Re: Problem with default partition pruning

Hi, Amit. At Wed, 10 Apr 2019 10:48:38 +0900, Amit Langote wrote in <4ef8d47d-b0c7-3093-5aaa-226162c5b...@lab.ntt.co.jp> > > I think this is useful even counting possible degradation, and I > > believe generate_partition_qual is not called so often. > > I think more commonly used forms of sub-

Re: Enable data checksums by default

On Mon, Apr 1, 2019 at 10:16:47AM +0200, Christoph Berg wrote: > Re: Tomas Vondra 2019-03-30 <20190330192543.GH4719@development> > > I have not investigated the exact reasons, but my hypothesis it's about > > the amount of WAL generated during the initial CREATE INDEX (because it > > probably ends

Re: Enable data checksums by default

On Fri, Mar 22, 2019 at 12:07:22PM -0400, Tom Lane wrote: > Christoph Berg writes: > > I think, the next step in that direction would be to enable data > > checksums by default. They make sense in most setups, > > Well, that is exactly the point that needs some proof, not just > an unfounded asse

Re: pgsql: tableam: basic documentation.

On Wed, Apr 10, 2019 at 12:56 PM Michael Paquier wrote: > Hi Andres, > > On Thu, Apr 04, 2019 at 12:42:06AM +, Andres Freund wrote: > > tableam: basic documentation. > > > > This adds documentation about the user oriented parts of table access > > methods (i.e. the default_table_access_method

Re: Problem with default partition pruning

At Wed, 10 Apr 2019 11:17:53 +0900, Amit Langote wrote in <494124a7-d305-1bc9-ef64-d5c790e13...@lab.ntt.co.jp> > On 2019/04/09 17:37, Kyotaro HORIGUCHI wrote: > > At Tue, 9 Apr 2019 16:41:47 +0900, "Yuzuko Hosoya" > > wrote > >>> So still it is wrong that the new code is added at the beginning

Re: Problem with default partition pruning

Hi. (The thread seems broken for Thunderbird) At Wed, 10 Apr 2019 11:24:11 +0900, "Yuzuko Hosoya" wrote in <00df01d4ef44$7bb79370$7326ba50$@lab.ntt.co.jp> > > Why? If clauses contains a clause on a partition key, the clause is > > involved in determination of whether a partition survives or n

Re: pg_dump is broken for partition tablespaces

On Wed, 10 Apr 2019 at 11:05, Alvaro Herrera wrote: > > On 2019-Apr-09, Alvaro Herrera wrote: > > > There is one deficiency that needs to be solved in order for this to > > work fully: currently there is no way to reset "reltablespace" to 0. > > Therefore I propose to add > ALTER TABLE tb ... RESE

Re: Dependences records and comments

=?utf-8?B?0JTQvNC40YLRgNC40Lkg0JLQvtGA0L7QvdC40L0=?= writes: > When we create/alter object we already add dependency row to pg_depend > (or, pg_shdepend) table for object that is depends (e.g. trigger depends > on table which it created). But when I add comment on table, no one > dependency row i

Re: [HACKERS] Block level parallel vacuum

On Mon, Apr 8, 2019 at 7:25 PM Kyotaro HORIGUCHI wrote: > > Hello. > > # Is this still living? I changed the status to "needs review" > > At Sat, 6 Apr 2019 06:47:32 +0900, Masahiko Sawada > wrote in > > > Indeed. How about the following description? > > > > > > > Attached the updated version p

Re: Transaction commits VS Transaction commits (with parallel) VS query mean time

On Mon, Apr 8, 2019 at 8:51 AM Amit Kapila wrote: > > On Mon, Apr 8, 2019 at 7:54 AM Jamison, Kirk wrote: > > So I am marking this thread as “Ready for Committer”. > > > > Thanks, Hari and Jamison for verification. The patches for > back-branches looks good to me. I will once again verify them

Re: Problem with default partition pruning

On 2019/04/10 12:53, Kyotaro HORIGUCHI wrote: > At Wed, 10 Apr 2019 11:17:53 +0900, Amit Langote > wrote: >> Yeah, I think we should move the "if (partconstr)" block to the "if >> (is_orclause(clause))" block as I originally proposed in: >> >> https://www.postgresql.org/message-id/9bb31dfe-b0d0-5

Re: Problem with default partition pruning

On 2019/04/10 14:55, Amit Langote wrote: > 2. Hosoya-san reported on 2019/03/22 that a contradictory WHERE clause > applied to a *partition* doesn't return an empty plan: > >> I understood Amit's proposal. But I think the issue Thibaut reported >> would occur regardless of whether clauses have O

Re: Experimenting with hash join prefetch

On Sun, Oct 14, 2018 at 11:11 PM Andrey Borodin wrote: > > 14 окт. 2018 г., в 9:18, Thomas Munro > > написал(а): > > > > + /* Prefetch the bucket for the next key */ > > + uint32 next_hash = hash_uint32(DatumGetInt32(keyval) + 1); > > + uint32 next_bucke

  1   2   >