Re: [HACKERS] path toward faster partition pruning

On 12 December 2017 at 22:13, Amit Langote wrote: > Attached updated patches. Hi Amit, I was also wondering about your thoughts on the design of get_partitions_for_keys() and more generally how there are many functions which have some special treatment doing

Re: Statically linking ICU with Postgres

IMO the whole idea behind building Postgres with ICU was to remove the dependency provided by the OS package. Installing ICU as shared object and configuring Postgres with the libicu*.so file may have a dependency on LD_LIBRARY_PATH. In shared object situation un-setting/re-setting the

Re: [HACKERS] path toward faster partition pruning

On 19 December 2017 at 17:36, David Rowley wrote: > Also, instead of using bms_intersect here, would it be better to do: > > result = bms_del_members(result, or_partset); ? I should have said bms_int_members() rather than bms_del_members() -- David Rowley

Re: [HACKERS] path toward faster partition pruning

On 12 December 2017 at 22:13, Amit Langote wrote: > Attached updated patches. Hi Amit, I'm sorry to say this is another micro review per code I'm stumbling over when looking at the run-time partition pruning stuff. 1. In get_partitions_from_clauses_recurse(),

Re: Statically linking ICU with Postgres

On Tue, Dec 19, 2017 at 12:10 PM, leoaaryan wrote: > I can see libicu*.a in the directory /leoaaryan/postgres-10/lib. But I'm not > able to make the postgres source code with it. > ./configure --prefix=/leoaaryan/postgres-10 ... --with-icu >

Statically linking ICU with Postgres

I was able to link ICU library with postgres as shared objects using the configure command: ./configure --prefix=/leoaaryan/postgres-10 ... --with-icu ICU_CFLAGS="-I/leoaaryan/postgres-10/include" ICU_LIBS="-L/leoaaryan/postgres-10/lib -licuuc -licudata -licui18n" Now I'm trying link ICU with

Re: [HACKERS] Add support for tuple routing to foreign partitions

On 2017/12/18 23:25, Alvaro Herrera wrote: > (I wonder why > this function needs a local variable "partition_check" -- seems > pointless). Before 15ce775faa4 [1], there were more than one line where partition_check was being set, but maybe it still didn't have to be a separate variable. Thanks,

Re: Tracking of page changes for backup purposes. PTRACK [POC]

On Tue, Dec 19, 2017 at 2:57 AM, Robert Haas wrote: > I think this doesn't really show much because it's apparently limited > by the speed of fsync() on your filesystem. You might try running the > test with synchronous_commit=off. You may want to run Postgres on scissors

Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.

On Tue, Dec 19, 2017 at 5:11 AM, Masahiko Sawada wrote: > On Tue, Dec 19, 2017 at 3:52 AM, Fujii Masao wrote: >> Committed. Thanks! > > Thank you! Thanks all. I can see that I have been credited as author as well, though it seems to me that I played

Re: BUG #14941: Vacuum crashes

On 12/18/17, 3:30 PM, "Masahiko Sawada" wrote: > According to the following old comment, there might be reason why we > didn't pass the information to vacuum_rel(). But your patch fetches > the relation > name even if the "relation" is not provided. I wonder if it can be >

Re: Logical replication without a Primary Key

On 18/12/17 21:57, Joshua D. Drake wrote: > On 12/18/2017 12:52 PM, Andres Freund wrote: >> >> Just ot make sure: You're saying there's no problem here, and that >> logical rep is behaving correctly, right? > > Correct. I am not sure where the miscommunication was (fully willing to > accept it

Re: Logical replication without a Primary Key

On 12/18/2017 12:52 PM, Andres Freund wrote: Just ot make sure: You're saying there's no problem here, and that logical rep is behaving correctly, right? Correct. I am not sure where the miscommunication was (fully willing to accept it was on my side) but if I update multiple rows in a

Re: Logical replication without a Primary Key

On 2017-12-18 12:43:24 -0800, Joshua D. Drake wrote: > This is the behavior I was expecting. As I said, I may have misunderstood > the responses but it is acting as I would expect. Just ot make sure: You're saying there's no problem here, and that logical rep is behaving correctly, right? FWIW,

Re: Logical replication without a Primary Key

On 12/07/2017 12:39 PM, Andres Freund wrote: Not a problem. If you updated both rows, then there's two cases: a) the update actually changed the column values. In which case the first per-row change that's replicated updates the first row, but the second one won't again find it as

Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.

On Tue, Dec 19, 2017 at 3:52 AM, Fujii Masao wrote: > On Fri, Dec 15, 2017 at 9:51 AM, Masahiko Sawada > wrote: >> On Fri, Dec 15, 2017 at 6:46 AM, Michael Paquier >> wrote: >>> On Fri, Dec 15, 2017 at 3:52 AM, Fujii

Re: [HACKERS] static assertions in C++

On 12/11/17 17:12, Tom Lane wrote: > Peter Eisentraut writes: >> On 12/11/17 16:45, Tom Lane wrote: >>> (BTW, why is it that we can't fall back on the negative-width-bitfield >>> trick for old g++?) > >> The complaint is >> error: types may not be defined in

Re: File name as application name in regression tests and elsewhere

On 12/18/17 06:59, Andrew Dunstan wrote: > I was doing some work over the weekend and it occurred to me that it > would be quite nice to have the input file name from regression tests > set as the application name, and then use a log_line_prefix setting > including %a, so that this would appear on

Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.

On Fri, Dec 15, 2017 at 9:51 AM, Masahiko Sawada wrote: > On Fri, Dec 15, 2017 at 6:46 AM, Michael Paquier > wrote: >> On Fri, Dec 15, 2017 at 3:52 AM, Fujii Masao wrote: >>> On Mon, Dec 11, 2017 at 2:16 PM, Michael

Re: autoprewarm is fogetting to register a tranche.

On Fri, Dec 15, 2017 at 3:32 AM, Kyotaro HORIGUCHI wrote: > Hello, I noticed while an investigation that pg_prewarm is > forgetting to register a tranche. Oops. > In passing, I found it hard to register a tranche in > apw_init_shmem() because a process using the

Re: es_query_dsa is broken

On Sun, Dec 17, 2017 at 7:35 PM, Thomas Munro wrote: > Andreas Seltenreich found a query[1] that suffers from this bug > (thanks!), and Amit confirmed that this patch fixes it, but further > sqlsmith fuzz testing with the patch applied also revealed that it > failed

Re: Protect syscache from bloating with negative cache entries

On Mon, Dec 18, 2017 at 11:46 AM, Andres Freund wrote: > I'm not 100% convinced either - but I also don't think it matters all > that terribly much. As long as the overall hash hit rate is decent, > minor increases in the absolute number of misses don't really matter > that

Re: Protect syscache from bloating with negative cache entries

On 2017-12-17 19:23:45 -0500, Robert Haas wrote: > On Sat, Dec 16, 2017 at 11:42 PM, Andres Freund wrote: > >> I'm not sure we should regard very quick bloating as a problem in need > >> of solving. Doesn't that just mean we need the cache to be bigger, at > >> least

Re: [HACKERS] Custom compression methods

On Mon, Dec 18, 2017 at 10:43 AM, Tomas Vondra wrote: > I personally am not quite convinced about that, for the reason I tried > to explain in my previous messages. I see it as a poor alternative to > compression built into the data type. I do like the idea of

Re: [HACKERS] Proposal: Local indexes for partitioned table

On Mon, Dec 18, 2017 at 11:02 AM, Alvaro Herrera wrote: > After this discussion, this is how I see things working: > > 1. pg_dump >a) creates indexes on partitions normally >b) once all existing indexes are done, index on parent is created, > with ONLY. No

Re: [HACKERS] Proposal: Local indexes for partitioned table

After this discussion, this is how I see things working: 1. pg_dump a) creates indexes on partitions normally b) once all existing indexes are done, index on parent is created, with ONLY. No cascading occurs, no indexes are attached. c) ATTACH is run for each existing partition

Re: [HACKERS] Custom compression methods

On 12/17/2017 04:32 AM, Robert Haas wrote: > On Thu, Dec 14, 2017 at 12:23 PM, Tomas Vondra > wrote: >> Can you give an example of such algorithm? Because I haven't seen such >> example, and I find arguments based on hypothetical compression methods >> somewhat

Re: [HACKERS] [PATCH] Improve geometric types

> Does this patch series fix bug #14971? No, it doesn't. I am trying to improve things without touching the EPSILON.

pltcl valgrind output

I've been adding support for valgrind to the buildfarm client (code will hit the git repo shortly). Mostly the results have been pretty clean, but the pltcl tests generated the attached output. Perhaps someone with more valgrind-fu than I have so far would like to use the information to extend

Re: [HACKERS] [PATCH] Improve geometric types

Does this patch series fix bug #14971? https://www.postgresql.org/message-id/20171213172806.20142.73...@wrigleys.postgresql.org Eric: see https://www.postgresql.org/message-id/CAE2gYzzvp=uvpw4fytoaevyk-wze4jw7u2s1glrok35mr1-...@mail.gmail.com for last version of patch. Motivation for patch is at

Re: [HACKERS] Add support for tuple routing to foreign partitions

InitResultRelInfo becomes unintelligible after this patch -- it was straightforward but adding partition_root makes things shaky. Please add a proper comment indicating what each argument is. (I wonder why this function needs a local variable "partition_check" -- seems pointless). -- Álvaro

RE: User defined data types in Logical Replication

Hi Petr Jelineks, Sawada-san > I think the changes make sense in terms of how it all works now. > > That said I don't think the renaming idea is a good one, the naming was > chosen to be future proof because eventually we'll need to map types to > local oid (and possibly more) where the local

Re: GSoC 2018

Aleksander, * Aleksander Alekseev (a.aleks...@postgrespro.ru) wrote: > Thanks you a lot for your feedback. I modified the project description > to make it more clear that it implies augmenting an existing HA > solution, particularly Stolon, and doesn't imply solving existing > limitations of

Re: User defined data types in Logical Replication

Hi, On 18/12/17 14:28, Huong Dangminh wrote: Your patch is fine for me. But logicalrep_typmap_getid will be unused. >>> >>> Yeah, actually we don't use LogicalRepTyp.typoid as well. If we allow >>> to replicate data to an another data type of column, what is the data >>> type

RE: User defined data types in Logical Replication

Hi Sawada-san, > > Sent: Tuesday, December 12, 2017 9:41 AM > > To: Dang Minh Huong > > Cc: PostgreSQL Hackers ; Yanagisawa > > Hiroshi(柳澤 博) ; Dangminh Huong(ダン > Ｍ > > フーン) > >

RE: User defined data types in Logical Replication

Hi Sawada-san, > Sent: Tuesday, December 12, 2017 9:41 AM > To: Dang Minh Huong > Cc: PostgreSQL Hackers ; Yanagisawa > Hiroshi(柳澤 博) ; Dangminh Huong(ダンＭ > フーン) > Subject: Re: User

Re: genomic locus

On 16 December 2017 at 03:49, Gene Selkov wrote: > Greetings everyone, > > I need a data type to represent genomic positions, which will consist of a > string and a pair of integers with interval logic and access methods. Sort > of like my seg type, but more straightforward.

Re: Tracking of page changes for backup purposes. PTRACK [POC]

Hello! Thanks for sharing this work! I think this is important feature to make backups more efficient. > 18 дек. 2017 г., в 15:18, Anastasia Lubennikova > написал(а): > > Patches for v 10.1 and v 9.6 are attached. > Since ptrack is basically just an API for use

Re: File name as application name in regression tests and elsewhere

Hello Andrew, > I was doing some work over the weekend and it occurred to me that it > would be quite nice to have the input file name from regression tests > set as the application name, and then use a log_line_prefix setting > including %a, so that this would appear on the logs. > > My first

File name as application name in regression tests and elsewhere

I was doing some work over the weekend and it occurred to me that it would be quite nice to have the input file name from regression tests set as the application name, and then use a log_line_prefix setting including %a, so that this would appear on the logs. My first thought was to alter all

Re: Tracking of page changes for backup purposes. PTRACK [POC]

Hello Anastasia, Personally I'm very glad PTRACK is finally proposed to be ported to the community PostgreSQL. > Since ptrack is basically just an API for use in backup tools, it is > impossible to test the patch independently. I believe it's worth to create an extension that will provide

Re: [HACKERS] Add support for tuple routing to foreign partitions

(2017/12/18 18:14), Amit Langote wrote: I noticed that this patch introduces a partition_rels field in ModifyTable, which contains the RT indexes of *all* leaf partitions in the partition tree. That means we now expand the partition inheritance tree in the planner even in the INSERT case,

Re: genomic locus

hello … maybe this one is also helpful: https://wiki.postgresql.org/images/1/1b/Postbis_pgcon_eu_2012.pdf it seems they have put a lot of work into that. regards, hans > On 15 Dec 2017, at 20:49, Gene Selkov wrote: > > Greetings everyone, > > I

Re: [HACKERS] Runtime Partition Pruning

On 18 December 2017 at 21:31, Amit Langote wrote: > On 2017/12/16 15:05, David Rowley wrote: >> I've been looking over this and I think that the use of the >> PartitionDispatch in set_append_subplan_indexes is not correct. What >> we need here is the index of the

Re: GSoC 2018

Hello hackers, Thanks you a lot for your feedback. I modified the project description to make it more clear that it implies augmenting an existing HA solution, particularly Stolon, and doesn't imply solving existing limitations of logical replication like lack of DDL replication. Removing some

Re: [HACKERS] Custom compression methods

On Thu, 14 Dec 2017 10:29:10 -0500 Robert Haas wrote: > On Wed, Dec 13, 2017 at 7:18 AM, Ildus Kurbangaliev > wrote: > > Since we agreed on ALTER syntax, i want to clear things about > > CREATE. Should it be CREATE ACCESS METHOD .. TYPE

Re: [HACKERS] Runtime Partition Pruning

On 2017/12/09 0:57, Robert Haas wrote: > On Thu, Dec 7, 2017 at 2:22 AM, Beena Emerson wrote: >> I have added the partition quals that are used for pruning. >> >> PFA the updated patch. I have changed the names of variables to make >> it more appropriate, along with

Re: [HACKERS] Runtime Partition Pruning

Hi. On 2017/12/16 15:05, David Rowley wrote: > On 13 December 2017 at 00:33, Beena Emerson wrote: >> PFA the updated patch, this can be applied over the v13 patches [1] >> over commit 487a0c1518af2f3ae2d05b7fd23d636d687f28f3 > > Hi Beena, > > Thanks for posting an