Re: [HACKERS] path toward faster partition pruning

Horiguchi-san, Thanks for the review. On 2018/01/30 20:43, Kyotaro HORIGUCHI wrote: > At Tue, 30 Jan 2018 09:57:44 +0900, Amit Langote wrote: >> AFAICS, v22 cleanly applies to HEAD (c12693d8f3 [1]), compiles, and make > I have some random comments on 0002. > > -extract_partition_key_clauses

Re: JIT compiling with LLVM v9.0

On 31.01.2018 05:48, Thomas Munro wrote: This seems to be a valid complaint. I don't think you should be (indirectly) wrapping Types.h in extern "C". At a guess, your llvmjit.h should be doing its own #ifdef __cplusplus'd linkage specifiers, so you can use it from C or C++, but making sure

Re: csv format for psql

Pavel Stehule wrote: > This format is too important, so some special short or long option can be > practical (it will be printed in help) > > some like --csv I guess -C/--csv could be used, like there already is -H/--html. > I found one issue - PostgreSQL default field separator is

Re: [HACKERS] Why forcing Hot_standby_feedback to be enabled when creating a logical decoding slot on standby

Hi, I am trying to create logical decoding slot on a standby. Enabling Hot_standby_feedback on standby is one of the requirement ; which will delay vacuuming of stale data on Master server. I am working on a hack to avoid Hot_standby_feedback so that Standby doesn't have any dependency on Master

Re: csv format for psql

2018-01-31 13:58 GMT+01:00 Daniel Verite : > Pavel Stehule wrote: > > > This format is too important, so some special short or long option can be > > practical (it will be printed in help) > > > > some like --csv > > I guess -C/--csv could be used, like there

Re: [HACKERS] generated columns

On Thu, Jan 25, 2018 at 10:26:55PM -0500, Peter Eisentraut wrote: > On 1/19/18 00:18, Michael Paquier wrote: >> +SELECT a, c FROM gtest12; -- FIXME: should be allowed >> +ERROR: permission denied for function gf1 > > This is quite hard to fix and I would like to leave this for a future >

CURRENT OF causes an error when IndexOnlyScan is used

Hi, I found that updating a cursor by using CURRENT OF causes the following error when the query is executed by IndexOnlyScan. ERROR: cannot extract system attribute from virtual tuple IndexOnlyScan returns a virtual tuple that doesn't have system column, so we can not get ctid in the same

Re: CURRENT OF causes an error when IndexOnlyScan is used

On Thu, 1 Feb 2018 01:33:49 +0900 Yugo Nagata wrote: I'm sorry the patch attached in the previous mail is broken and not raises a compile error. I attached the fixed patch. Regards, > Hi, > > I found that updating a cursor by using CURRENT OF causes the > following error

Re: Wait for parallel workers to attach

On Wed, Jan 31, 2018 at 3:57 AM, Amit Kapila wrote: >> * There might be some opportunity to share some of the new code with >> the code recently committed to WaitForParallelWorkersToFinish(). For >> one thing, the logic in this block could be refactored into a >>

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 10:22 AM, Peter Eisentraut wrote: > On 1/30/18 21:55, Andres Freund wrote: >> I'm open to changing my mind on it, but it seems a bit weird that a >> feature that relies on a shlib being installed magically turns itself on >> if avaible.

Re: JIT compiling with LLVM v9.0

On 1/30/18 21:55, Andres Freund wrote: > I'm open to changing my mind on it, but it seems a bit weird that a > feature that relies on a shlib being installed magically turns itself on > if avaible. And leaving that angle aside, ISTM, that it's a complex > enough feature that it should be opt-in

Re: [HACKERS] Can ICU be used for a database's default sort order?

Hi. > 23 июня 2017 г., в 21:32, Peter Eisentraut > написал(а): > > On 6/22/17 23:10, Peter Geoghegan wrote: >> On Thu, Jun 22, 2017 at 7:10 PM, Tom Lane wrote: >>> Is there some way I'm missing, or is this just a not-done-yet feature? >>

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] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 2:28 PM, Peter Geoghegan wrote: > What's at issue here specifically is the exact behavior of > EvalPlanQual() in the context of having *multiple* sets of WHEN quals > that need to be evaluated one at a time (in addition to conventional > EPQ join quals). This

Re: Temporary tables prevent autovacuum, leading to XID wraparound

On Tue, Jan 30, 2018 at 7:04 PM, Tsunakawa, Takayuki wrote: > So a simple improvement would be to assign workers fairly to databases facing > a wraparound risk, as Sawada-san suggested. Is that always an improvement, or does it make some cases better and others

Re: JIT compiling with LLVM v9.0

On Tue, Jan 30, 2018 at 5:57 PM, Andres Freund wrote: > Given that we need a shared library it'll be best buildsystem wise if > all of this is in a directory, and there's a separate file containing > the stubs that call into it. > > I'm not quite sure where to put the code.

Re: [HACKERS] MERGE SQL Statement for PG11

On Wed, Jan 31, 2018 at 7:17 AM, Robert Haas wrote: > I don't fully grok merge but suppose you have: > > WHEN MATCHED AND a = 0 THEN UPDATE ... > WHEN MATCHED AND a = 1 THEN UPDATE ... > WHEN NOT MATCHED THEN INSERT ... > > Suppose you match a tuple with a = 0 but, upon

Interesting paper: Contention-Aware Lock Scheduling

Hi hackers, I saw this today: http://www.vldb.org/pvldb/vol11/p648-tian.pdf It describes the "LDSF" (largest-dependency-set-first) lock scheduling algorithm and related work, as an alternative to the FIFO scheduling used by PostgreSQL and most other RDBMSs. LDSF been implemented in MySQL 8.

Re: JIT compiling with LLVM v9.0

On 2018-01-31 14:45:46 -0500, Robert Haas wrote: > On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund wrote: > >> The first one is a problem that's not going to go away. If the > >> problem of JIT being enabled "magically" is something we're concerned > >> about, we need to

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-31 11:53:25 -0500, Robert Haas wrote: > On Wed, Jan 31, 2018 at 10:22 AM, Peter Eisentraut > wrote: > > On 1/30/18 21:55, Andres Freund wrote: > >> I'm open to changing my mind on it, but it seems a bit weird that a > >> feature that relies on a

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-31 11:56:59 -0500, Robert Haas wrote: > On Tue, Jan 30, 2018 at 5:57 PM, Andres Freund wrote: > > Given that we need a shared library it'll be best buildsystem wise if > > all of this is in a directory, and there's a separate file containing > > the stubs that

Re: Documentation of pgcrypto AES key sizes

On Sun, Jan 28, 2018 at 6:02 PM, Thomas Munro wrote: > Added to the next CF. Committed. I also modified the reference in the regression test along similar lines, and for good measure, I back-patched this change, as it constitutes a clear error in the

[WIP PATCH] Index scan offset optimisation using visibility map

Hello. WIP-Patch for optimisation of OFFSET + IndexScan using visibility map. Patch based on idea of Maxim Boguk [1] with some inspiration from Douglas Doole [2]. - Everyone knows - using OFFSET (especially big) is not an good practice. But in reality they widely used mostly for paging

Re: proposal: alternative psql commands quit and exit

On Sun, Jan 28, 2018 at 06:35:06PM -0500, Bruce Momjian wrote: > I used Robert's patch and modified it to match the ideas I had above. > Specifically no white space can be before 'help', 'exit' or 'quit' and > prompt_status is used to adjust the suggestion. Here is the visible > behavior: So

Re: autoprewarm is fogetting to register a tranche.

On Fri, Dec 22, 2017 at 12:13 AM, Kyotaro HORIGUCHI wrote: > The attached one-liner patch is just adding tranche registration > to autprewarm.c. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: A typo in error message

On Wed, Jan 31, 2018 at 12:53 AM, Michael Paquier wrote: > On Wed, Jan 31, 2018 at 08:47:57AM +0300, Alexander Lakhin wrote: >> Please consider committing the attached patch to fix a typo in error >> message. > > Yeah.. Committed. >> if (cxt->ofType) >>

Re: pgsql: doc: clearify trigger behavior for inheritance

On Wed, Jan 31, 2018 at 5:00 PM, Bruce Momjian wrote: > doc: clearify trigger behavior for inheritance > > The previous wording added in PG 10 wasn't specific enough about the > behavior of statement and row triggers when using inheritance. This may be a good change in

Re: list partition constraint shape

On Mon, Jan 29, 2018 at 1:22 AM, Amit Langote wrote: >> Updated patch attached. Because I made no changes >> other than that, I'll make this as Ready for Committer. > Thanks a lot for reviewing. Committed and back-patched to v10. -- Robert Haas EnterpriseDB:

Re: pgsql: doc: clearify trigger behavior for inheritance

On Wed, Jan 31, 2018 at 05:13:41PM -0500, Robert Haas wrote: > On Wed, Jan 31, 2018 at 5:00 PM, Bruce Momjian wrote: > > doc: clarify trigger behavior for inheritance > > > > The previous wording added in PG 10 wasn't specific enough about the > > behavior of statement and row

Re: WINDOW RANGE patch versus leakproofness

On Wed, Jan 31, 2018 at 5:52 AM, Dean Rasheed wrote: > On 30 January 2018 at 16:42, Tom Lane wrote: >> So I'm thinking that (a) we do not need to check for leaky functions used >> in window support, and (b) therefore there's no need to avoid leaky >>

Re: WINDOW RANGE patch versus leakproofness

On 31 January 2018 at 21:51, Robert Haas wrote: > On Wed, Jan 31, 2018 at 5:52 AM, Dean Rasheed > wrote: >> On 30 January 2018 at 16:42, Tom Lane wrote: >>> So I'm thinking that (a) we do not need to check for leaky functions

Re: Add RANGE with values and exclusions clauses to the Window Functions

On Wed, Jan 31, 2018 at 5:06 PM, Tom Lane wrote: > We could imagine reimplementing WinGetFuncArgInFrame to fix this, but > aside from the sheer inefficiency of simple fixes, I'm not very clear > what seeking relative to WINDOW_SEEK_CURRENT should mean when the current > row

Re: [HACKERS] Surjective functional indexes

On 10 January 2018 at 09:54, Konstantin Knizhnik wrote: > (new version attached) Why this comment? Current implementation of projection optimization has to calculate index expression twice in case of hit (value of index expression is not changed) and three times if

Re: [HACKERS] [PATCH] Lockable views

On Thu, 01 Feb 2018 09:48:49 +0900 (JST) Tatsuo Ishii wrote: > > On Tue, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote: > >> Looks good to me. If there's no objection, especially from Thomas > >> Munro, I will mark this as "ready for committer". > > > > No

Re: [HACKERS] path toward faster partition pruning

On 31 January 2018 at 21:03, Amit Langote wrote: > Update patch set attached. Thanks again. (My apologies for being slow to respond here. I've been on leave this week and I'm off again next week. I now have a little time to reply) Hi Amit, Thanks for

Re: Add RANGE with values and exclusions clauses to the Window Functions

Oliver Ford writes: > [ 0001-window-frame-v11.patch ] I've realized that the exclusion clause aspect of this patch is rather badly broken. In particular, the "seek to row" logic in WinGetFuncArgInFrame is critically dependent on the assumption that the rows of the frame are

Re: Temporary tables prevent autovacuum, leading to XID wraparound

On Thu, Feb 1, 2018 at 2:01 AM, Robert Haas wrote: > On Tue, Jan 30, 2018 at 7:04 PM, Tsunakawa, Takayuki > wrote: >> So a simple improvement would be to assign workers fairly to databases >> facing a wraparound risk, as Sawada-san

Re: [HACKERS] [PATCH] Lockable views

> On Tue, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote: >> Looks good to me. If there's no objection, especially from Thomas >> Munro, I will mark this as "ready for committer". > > No objection from me. I marked this as "Ready for Committer". Best regards, -- Tatsuo Ishii

Re: CURRENT OF causes an error when IndexOnlyScan is used

Yugo Nagata writes: > I'm sorry the patch attached in the previous mail is broken and > not raises a compile error. I attached the fixed patch. This patch is almost certainly wrong: you can't assume that the scan-level state matches the tuple we are currently processing at

Re: [HACKERS] [PATCH] Lockable views

On Tue, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote: > Looks good to me. If there's no objection, especially from Thomas > Munro, I will mark this as "ready for committer". No objection from me. -- Thomas Munro http://www.enterprisedb.com

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

On Fri, Jan 26, 2018 at 05:58:48PM -0500, Tom Lane wrote: > Daniel Gustafsson writes: >> Oversight, completely missed that one. > > It looks like no core code uses that macro, so it's got no effect > unless some third-party code does ... but I changed it anyway. Good point. I

Re: list partition constraint shape

On 2018/02/01 6:08, Robert Haas wrote: > On Mon, Jan 29, 2018 at 1:22 AM, Amit Langote > wrote: >>> Updated patch attached. Because I made no changes >>> other than that, I'll make this as Ready for Committer. >> Thanks a lot for reviewing. > > Committed and

Re: [HACKERS] generated columns

On Wed, Jan 31, 2018 at 10:18:04PM +0900, Michael Paquier wrote: > On Thu, Jan 25, 2018 at 10:26:55PM -0500, Peter Eisentraut wrote: >> On 1/19/18 00:18, Michael Paquier wrote: >>> +SELECT a, c FROM gtest12; -- FIXME: should be allowed >>> +ERROR: permission denied for function gf1 >> >> This

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Thu, Feb 1, 2018 at 11:05 AM, Michael Paquier wrote: > On Sat, Jan 13, 2018 at 03:40:01PM +, Simon Riggs wrote: > > The new two byte value is protected by CRC. The 2 byte value repeats > > every 32768 WAL files. Any bit error in that value that made it appear >

Re: Re: BUG #15039: some question about hash index code

On Wed, Jan 31, 2018 at 6:14 PM, Amit Kapila wrote: > On Wed, Jan 31, 2018 at 5:57 PM, 自己 wrote: >> thank you for your quick reply. >> and i have another question, for the following code, whether exist such >> scene : page_found is false and >>

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Sat, Jan 13, 2018 at 03:40:01PM +, Simon Riggs wrote: > The new two byte value is protected by CRC. The 2 byte value repeats > every 32768 WAL files. Any bit error in that value that made it appear > to be a current value would need to have a rare set of circumstances. If you use the two

Re: CURRENT OF causes an error when IndexOnlyScan is used

On Wed, 31 Jan 2018 21:12:51 -0500 Tom Lane wrote: > Yugo Nagata writes: > > I'm sorry the patch attached in the previous mail is broken and > > not raises a compile error. I attached the fixed patch. > > This patch is almost certainly wrong: you can't

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Wed, Jan 31, 2018 at 01:48:00AM +0100, Andreas Karlsson wrote: > I too like the concept, but have not had the time to look into it. This may happen at some point, for now I am marking the patch as returned with feedback. -- Michael signature.asc Description: PGP signature

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

On 30 January 2018 at 14:14, David G. Johnston wrote: > This bug has an obvious if annoying work-around and fixing the bug will > likely cause people's code, that uses said work-around, to fail. Breaking > people's working code in stable release branches is generally

Re: [HACKERS] WIP: Restricting pg_rewind to data/wal dirs

On Mon, Jan 22, 2018 at 03:12:58PM -0500, Stephen Frost wrote: > I would think the next step here, as Michael suggested very early on in > this thread, would be to bring the exclude list and perhaps logic for > pg_basebackup into the common code and have pg_rewind leverage that > instead of having

Re: [HACKERS] taking stdbool.h into use

On Wed, Jan 24, 2018 at 03:44:04PM +0900, Michael Paquier wrote: > Good catch. Coverage reports mark those areas as empty! Similarly the > functions for record_* are mostly not used. Some tests could be added > for them at the same time. The four error paths of those functions are > tested as

constraint exclusion and nulls in IN (..) clause

Hi. When addressing a review comment on the fast partition pruning thread [1], I noticed that specifying null in the IN-list will cause constraint exclusion to wrongly fail to refute a table's check predicate. create table foo (a int check (a = 1)); insert into foo values (null), (1); --

Re: [HACKERS] Partition-wise aggregation/grouping

On Mon, Jan 29, 2018 at 3:42 AM, Jeevan Chalke wrote: > Attached new patch set and rebased it on latest HEAD. I strongly dislike add_single_path_to_append_rel. It adds branches and complexity to code that is already very complex. Most importantly, why are we

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 2:49 PM, Andres Freund wrote: >> We could do that, but I'd be more inclined just to let JIT be >> magically enabled. In general, if a user could do 'yum install ip4r' >> (for example) and have that Just Work without any further database >>

Re: Wait for parallel workers to attach

On Wed, Jan 31, 2018 at 9:53 PM, Robert Haas wrote: > On Wed, Jan 31, 2018 at 3:57 AM, Amit Kapila wrote: >>> * There might be some opportunity to share some of the new code with >>> the code recently committed to WaitForParallelWorkersToFinish().

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Jan 30, 2018 at 3:30 AM, Robert Haas wrote: > On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila wrote: >> If we want to get rid of Gather (Merge) checks in >> apply_projection_to_path(), then we need some way to add a projection >> path to the

Re: [HACKERS] [PATCH] Lockable views

On Tue, 30 Jan 2018 19:21:04 +1300 Thomas Munro wrote: > On Tue, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote: > >>> You need to DROP VIEW lock_view4 and lock_view5 in the regression > >>> test as well. > >> > >> Thank you for reviewing the

Re: Wait for parallel workers to attach

On Mon, Jan 29, 2018 at 4:01 AM, Peter Geoghegan wrote: > On Sat, Jan 27, 2018 at 12:14 AM, Amit Kapila wrote: > > I also found that all of these errors were propagated. The patch helps > parallel CREATE INDEX as expected/designed. > Great! > Some small

Re: [HACKERS] [PATCH] Improve geometric types

At Wed, 31 Jan 2018 13:09:09 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20180131.130909.210233873.horiguchi.kyot...@lab.ntt.co.jp> > At Sun, 21 Jan 2018 21:59:19 +0100, Emre Hasegeli wrote > in

Re: csv format for psql

Fabien COELHO wrote: > > This patch implements csv as an output format in psql > > (\pset format csv). > > Would you consider registering it in the next CF? Done here: https://commitfest.postgresql.org/17/1500/ Best regards, -- Daniel Vérité PostgreSQL-powered mailer:

Re: Help needed in using 'on_dsm_detach' callback

Hello Thomas, Thank you for your suggestions, needless to say it helped a lot. As you suggested, I have created an initial dsm segment and used it create dsa area as well as to detach dsm. Thus, it helped me in using 'on_dsm_detach' callback. I have tested the code and it

Re: Transform for pl/perl

Hello, On Fri, Jan 12, 2018 at 11:47:39AM +0300, Anthony Bykov wrote: > Hello, thank you for your message. > The problem was that different perl compilers uses different infinity > representations. Some of them use "Inf" others - use "inf". So, in > attachments there is a new version of the

Re: WINDOW RANGE patch versus leakproofness

On 30 January 2018 at 16:42, Tom Lane wrote: > So I'm thinking that (a) we do not need to check for leaky functions used > in window support, and (b) therefore there's no need to avoid leaky > behavior in in_range support functions. Objections? > Yes, I concur. Since window

Re: constraint exclusion and nulls in IN (..) clause

On Thu, Feb 1, 2018 at 12:26 PM, Amit Langote wrote: > Hi. > > When addressing a review comment on the fast partition pruning thread [1], > I noticed that specifying null in the IN-list will cause constraint > exclusion to wrongly fail to refute a table's check