Re: [HACKERS] Some questions about the array.

On Monday 30 November 2015 08:58:49 you wrote: > +1 IMO this line of thinking is a dead end. Better handled via > functions, not syntax Maybe then add array_pyslice(start, end) when start is 0 and with negative indexes? Only for 1D array. What do you think? -- YUriy Zhuravlev Postgres

Re: [HACKERS] On-demand running query plans using auto_explain and signals

Hello, On 15/10/2015 16:04, Pavel Stehule wrote: > > > 2015-10-15 15:42 GMT+02:00 Tom Lane >: > > "Shulgin, Oleksandr" > writes: > > I was thinking about this and

Re: [HACKERS] Freeze avoidance of very large table.

On Mon, Nov 30, 2015 at 9:18 AM, Masahiko Sawada wrote: > On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes wrote: >> On Tue, Nov 24, 2015 at 3:13 PM, Masahiko Sawada >> wrote: >>> >>> Yeah, we need to consider to compute checksum

Re: [HACKERS] Remaining 9.5 open items

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > > The non-documentation question is around DROP OWNED. We need to either > > have policies dropped by DROP OWNED (well, roles removed, unless it's > > the last one, in which case the policy should be dropped), or

Re: [HACKERS] Memory prefetching while sequentially fetching from SortTuple array, tuplestore

On Sun, Nov 29, 2015 at 10:14 PM, Peter Geoghegan wrote: > I'm currently running some benchmarks on my external sorting patch on > the POWER7 machine that Robert Haas and a few other people have been > using for some time now [1]. So far, the benchmarks look very good > across a

[HACKERS] gincostestimate and hypothetical indexes

Hello, I figured out that it's not possible to use a hypothetical gin index, as the gincostestimate function try to retrieve some statistical data from the index meta page. Attached patch fixes this. I believe this should be back-patched as was a2095f7fb5a57ea1794f25d029756d9a140fd429. Regards.

Re: [HACKERS] Remaining 9.5 open items

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Well, it's December nearly, and we don't seem to be making much progress > towards pushing out 9.5.0. I see the following items on > https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items > > * Open Row-Level Security Issues > > Seems like what's

Re: [HACKERS] Remaining 9.5 open items

Stephen Frost wrote: > The non-documentation question is around DROP OWNED. We need to either > have policies dropped by DROP OWNED (well, roles removed, unless it's > the last one, in which case the policy should be dropped), or update the > documentation to reflect that they don't. I had been

Re: [HACKERS] custom function for converting human readable sizes to bytes

Hi > 2. using independent implementation - there is some redundant code, but we > can support duble insted int, and we can support some additional units. > new patch is based on own implementation - use numeric/bigint calculations + regress tests and doc Regards Pavel diff --git

Re: [HACKERS] parallel joins, and better parallel explain

On Mon, Nov 30, 2015 at 4:52 PM, Robert Haas wrote: > Not only does this build only one copy of the hash table instead of N > copies, but we can parallelize the hash table construction itself by > having all workers insert in parallel, which is pretty cool. Hm. The case

Re: [HACKERS] parallel joins, and better parallel explain

On Thu, Nov 26, 2015 at 3:45 AM, Simon Riggs wrote: > Sounds like good progress. Thanks. > This gives us multiple copies of the hash table, which means we must either > use N * work_mem, or we must limit the hash table to work_mem / N per > partial plan. We use N *

Re: [HACKERS] Freeze avoidance of very large table.

On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes wrote: > On Tue, Nov 24, 2015 at 3:13 PM, Masahiko Sawada > wrote: >> >> Yeah, we need to consider to compute checksum if enabled. >> I've changed the patch, and attached. >> Please review it. > > Thanks

Re: [HACKERS] parallel joins, and better parallel explain

On Mon, Nov 30, 2015 at 12:01 PM, Greg Stark wrote: > On Mon, Nov 30, 2015 at 4:52 PM, Robert Haas wrote: >> Not only does this build only one copy of the hash table instead of N >> copies, but we can parallelize the hash table construction itself by >>

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > [ \rotate being a wrong name ] Here's an updated patch. First it renames the command to \crosstabview, which hopefully may be more consensual, at least it's semantically much closer to crosstab . > The important question is sorting output. The vertical header is

[HACKERS] Logical replication and multimaster

Hello all, We have implemented ACID multimaster based on logical replication and our DTM (distributed transaction manager) plugin. Good news is that it works and no inconsistency is detected. But unfortunately it is very very slow... At standalone PostgreSQL I am able to achieve about 3

Re: [HACKERS] Some questions about the array.

On Thu, Nov 26, 2015 at 6:08 AM, Teodor Sigaev wrote: > YUriy Zhuravlev wrote: >> >> On Friday 06 November 2015 12:55:44 you wrote: >>> >>> Omitted bounds are common in other languages and would be handy. I >>> don't think they'd cause any issues with multi-dimensional arrays or

Re: [HACKERS] Using quicksort for every external sort run

On Sat, Nov 28, 2015 at 4:05 PM, Peter Geoghegan wrote: > On Sat, Nov 28, 2015 at 2:04 PM, Jeff Janes wrote: ... >> >> The final merging is intermixed with whatever other work goes on to >> build the actual index files out of the sorted data, so I don't

Re: [HACKERS] Freeze avoidance of very large table.

On Mon, Nov 30, 2015 at 10:48:04PM +0530, Masahiko Sawada wrote: > On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes wrote: > > On Tue, Nov 24, 2015 at 3:13 PM, Masahiko Sawada > > wrote: > >> > >> Yeah, we need to consider to compute checksum if enabled.

Re: [HACKERS] Minor comment edits in nodeGather.c

On Tue, Nov 24, 2015 at 9:43 PM, Amit Langote wrote: > On 2015/11/25 11:31, Robert Haas wrote: >> On Tue, Nov 24, 2015 at 1:06 AM, Amit Langote >> wrote: >>> While going through nodeGather.c, I noticed portions of the file header >>>

Re: [HACKERS] Using quicksort for every external sort run

On Sun, Nov 29, 2015 at 8:02 PM, David Fetter wrote: >> >> For me very large sorts (100,000,000 ints) with work_mem below 4MB do >> better with unpatched than with your patch series, by about 5%. Not a >> big deal, but also if it is easy to keep the old behavior then I think >>

Re: [HACKERS] Additional role attributes && superuser review

* Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost wrote: > > * Michael Paquier (michael.paqu...@gmail.com) wrote: > >> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote: > >> > * Michael Paquier (michael.paqu...@gmail.com) wrote:

Re: [HACKERS] [patch] Proposal for \rotate in psql

2015-11-30 16:34 GMT+01:00 Daniel Verite : > Pavel Stehule wrote: > > > [ \rotate being a wrong name ] > > Here's an updated patch. > > First it renames the command to \crosstabview, which hopefully may > be more consensual, at least it's semantically much closer

Re: [HACKERS] Additional role attributes && superuser review

On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote: >> > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> >> It seems weird to not have a dedicated role

Re: [HACKERS] Freeze avoidance of very large table.

On 2015-11-30 12:58:43 -0500, Bruce Momjian wrote: > I would not bother mentioning this detail in the pg_upgrade manual page: > > + Since the format of visibility map has been changed in version 9.6, > + pg_upgrade creates and rewrite new > '_vm' > + file even if upgrading from 9.5 or

Re: [HACKERS] Freeze avoidance of very large table.

On Mon, Nov 30, 2015 at 07:05:21PM +0100, Andres Freund wrote: > On 2015-11-30 12:58:43 -0500, Bruce Momjian wrote: > > I would not bother mentioning this detail in the pg_upgrade manual page: > > > > + Since the format of visibility map has been changed in version 9.6, > > + pg_upgrade

Re: [HACKERS] Remaining 9.5 open items

On 2015-11-30 14:43:59 -0500, Tom Lane wrote: > * pg_rewind exiting with error code 1 when source and target are on the same > timeline > > Is this a new-in-9.5 bug, or a pre-existing problem? If the latter, > I'm not sure it's a release blocker. pg_rewind was only introduced in 9.5, no? > *

Re: [HACKERS] Remaining 9.5 open items

Tom Lane wrote: > * DDL deparsing testing module should have detected that transforms were not > supported, but it failed to notice that > > Is this really a release blocker? As a testing matter, it seems like any > fix would go into HEAD only. Not a blocker as far as I'm concerned. > *

[HACKERS] Remaining 9.5 open items

Well, it's December nearly, and we don't seem to be making much progress towards pushing out 9.5.0. I see the following items on https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items * Open Row-Level Security Issues Seems like what's left here is only documentation fixes, but they still

Re: [HACKERS] Additional role attributes && superuser review

Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: > > > I can think of a use-case for a user who can call pg_switch_xlog, but > > > not pg_start_backup()/pg_stop_backup(), but I have to admit that it > > > seems rather limited and I'm on the fence about it being a worthwhile > >

Re: [HACKERS] Using quicksort for every external sort run

On Mon, Nov 30, 2015 at 9:51 AM, Jeff Janes wrote: >> As I said, it seems a little bit unfair to hand-tune work_mem or >> maintenance_work_mem like that. Who can afford to do that? I think you >> agree that it's untenable to have DBAs allocate work_mem differently >> for

Re: [HACKERS] Using quicksort for every external sort run

On Mon, Nov 30, 2015 at 5:12 PM, Greg Stark wrote: > I think the take-away is that this is outside the domain where any > interesting break points occur. I think that these are representative of what people want to do with external sorts. We have already had Jeff look for a

Re: [HACKERS] Add EXTRA_CFLAGS to configure

On Wed, Oct 28, 2015 at 01:53:31PM +, Nathan Wagner wrote: > On Wed, Oct 28, 2015 at 02:42:19PM +0100, Robert Haas wrote: > > On Wed, Oct 28, 2015 at 2:17 PM, Andres Freund wrote: > > >> I use COPT for this purpose. > > > > > > Unless I miss something you can't just pass

Re: [HACKERS] Error with index on unlogged table

Hello, I studied your lastest patch. At Fri, 27 Nov 2015 16:59:20 +0900, Michael Paquier wrote in

Re: [HACKERS] Error with index on unlogged table

On Tue, Dec 1, 2015 at 11:11 AM, Kyotaro HORIGUCHI wrote: > Hello, I studied your latest patch. Thanks! > I feel quite uncomfortable that it solves the problem from a kind > of nature of unlogged object by arbitrary flagging which is not > fully corresponds to

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi > >> > Do you have some ideas about the name of this class? >> >> I think plpy.Error is fine. >> >> > here is updated patch - work with 2.x Python. > > I have 3.x Python broken on my fedora, so I should not do tests on 3.x. > here is complete patch - regress tests for all supported Python

Re: [HACKERS] proposal: multiple psql option -c

2015-11-30 15:17 GMT+01:00 Michael Paquier : > On Thu, Nov 26, 2015 at 4:21 AM, Pavel Stehule wrote: > > Attached patch per Tom Lane proposal. > > > > * multiple -c -f options are supported, the order of options is respected > > * the statements for one -c options are

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Thanks for the v7. Please check the comment below. -Table name in the vacuum progress + snprintf(progress_message[0], PROGRESS_MESSAGE_LENGTH, "%s.%s", schemaname,relname); In the vacuum progress, column table_name is showing first 30 characters of table name. postgres=# create table

Re: [HACKERS] 9.5Beta1 psql wrapped format expanded output

Jeff Janes writes: > On Fri, Oct 23, 2015 at 5:11 PM, Jeff Janes wrote: >> Why swidth for border 2 is three greater than it is with border 1, I >> don't really know. > Now I see why. Border 2 doesn't just add a '|' on either end of the line, > but

Re: [HACKERS] gincostestimate and hypothetical indexes

Julien Rouhaud writes: > I figured out that it's not possible to use a hypothetical gin index, as > the gincostestimate function try to retrieve some statistical data from > the index meta page. Good point. > Attached patch fixes this. I believe this should be

Re: [HACKERS] gincostestimate and hypothetical indexes

On 01/12/2015 00:37, Tom Lane wrote: > Julien Rouhaud writes: >> I figured out that it's not possible to use a hypothetical gin index, as >> the gincostestimate function try to retrieve some statistical data from >> the index meta page. > > Good point. > >> Attached

Re: [HACKERS] Using quicksort for every external sort run

Hm. Here is a log-log chart of those results (sorry for html mail). I'm not really sure if log-log is the right tool to use for a O(nlog(n)) curve though. I think the take-away is that this is outside the domain where any interesting break points occur. Maybe run more tests on the low end to find

Re: [HACKERS] Remaining 9.5 open items

On Tue, Dec 1, 2015 at 4:43 AM, Tom Lane wrote: > * pg_rewind exiting with error code 1 when source and target are on the same > timeline > > Is this a new-in-9.5 bug, or a pre-existing problem? If the latter, > I'm not sure it's a release blocker. pg_rewind has been

Re: [HACKERS] 9.5Beta1 psql wrapped format expanded output

On Mon, Nov 30, 2015 at 2:59 PM, Tom Lane wrote: > Jeff Janes writes: >> On Fri, Oct 23, 2015 at 5:11 PM, Jeff Janes wrote: >>> Why swidth for border 2 is three greater than it is with border 1, I >>> don't really know. > >> Now I

Re: [HACKERS] Remaining 9.5 open items

Stephen Frost wrote: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > Stephen Frost wrote: > > > > > The non-documentation question is around DROP OWNED. We need to either > > > have policies dropped by DROP OWNED (well, roles removed, unless it's > > > the last one, in which case the

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On 30 November 2015 at 22:27, Julien Rouhaud wrote: > I registered as reviewer on this, but after reading the whole thread for > the second time, it's still not clear to me if the last two submitted > patches (0001-Add-auto_explain.publish_plans.patch and >

Re: [HACKERS] Additional role attributes && superuser review

On Tue, Dec 1, 2015 at 3:32 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost wrote: >> > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> >> On Thu, Nov 19, 2015 at 7:10 AM,

Re: [HACKERS] Using quicksort for every external sort run

On Mon, Nov 30, 2015 at 12:29 PM, Peter Geoghegan wrote: >> I'm kind of curious as to why the optimal for the patched code appears >> at 1GB and not lower. If I get a chance to rebuild the test, I will >> look into that more. > > I think that the availability of abbreviated keys

Re: [HACKERS] Memory prefetching while sequentially fetching from SortTuple array, tuplestore

On Mon, Nov 30, 2015 at 1:04 PM, Peter Geoghegan wrote: > For example, the 50 million tuple test has over 8% of its runtime > shaved off. This seems to be a consistent pattern. I included the nitty-gritty details of this case in something attached to a mail I just sent, over in

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

On Thu, Nov 26, 2015 at 5:27 AM, Kouhei Kaigai wrote: > I'm now implementing. The above design perfectly works on ForeignScan. > On the other hands, I'd like to have deeper consideration for CustomScan. > > My recent patch adds LibraryName and SymbolName on CustomScanMethods

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

On 2015-12-01 05:00, David Rowley wrote: We already allow a SELECT's target list to contain non-aggregated columns in a GROUP BY query in cases where the non-aggregated column is functionally dependent on the GROUP BY clause. For example a query such as; SELECT p.product_id,p.description,

Re: [HACKERS] Minor comment edits in nodeGather.c

On 2015/12/01 3:06, Robert Haas wrote: > On Tue, Nov 24, 2015 at 9:43 PM, Amit Langote > wrote: >> On 2015/11/25 11:31, Robert Haas wrote: >>> >>> Well I think "scanning a plan" is clear enough even if it's >>> technically a Scan. >> >> Okay, ripped that out in the

Re: [HACKERS] Error with index on unlogged table

Hello, At Tue, 1 Dec 2015 11:53:35 +0900, Michael Paquier wrote in > On Tue, Dec 1, 2015 at 11:11 AM, Kyotaro HORIGUCHI > wrote: > > Hello, I studied your latest

[HACKERS] Removing Functionally Dependent GROUP BY Columns

We already allow a SELECT's target list to contain non-aggregated columns in a GROUP BY query in cases where the non-aggregated column is functionally dependent on the GROUP BY clause. For example a query such as; SELECT p.product_id,p.description, SUM(s.quantity) FROM product p INNER JOIN sale

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Mon, Nov 30, 2015 at 11:51 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Mon, Nov 30, 2015 at 6:28 AM, Noah Misch wrote: > >> > The proposed code is short on guidance about when to put a function in >> > TestLib >> > versus TestBase.

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Sorry for the confusing description and the chopped sentsnce. At Tue, 01 Dec 2015 16:25:57 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20151201.162557.184519961.horiguchi.kyot...@lab.ntt.co.jp> > Hello, > > At Mon, 30 Nov 2015 19:10:44 -0700

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, At Mon, 30 Nov 2015 19:10:44 -0700 (MST), Vinayak wrote in <1448935844520-5875614.p...@n5.nabble.com> > Thanks for the v7. > Please check the comment below. > -Table name in the vacuum progress > > + snprintf(progress_message[0], PROGRESS_MESSAGE_LENGTH, "%s.%s", >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Mon, 23 Nov 2015 12:12:23 -0500 Robert Haas wrote: > On Fri, Nov 20, 2015 at 6:53 AM, Ildus Kurbangaliev > wrote: > > We keep limited number of LWLocks in base shared memory, why not > > keep their thanches in shared memory too? Other

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On Wed, Nov 25, 2015 at 9:13 AM, Lukas Fittl wrote: > On Mon, Nov 23, 2015 at 11:53 PM, Peter Geoghegan wrote: > >> One specific justification he gave for not using pg_stat_statements was: >> >> "Doesn’t merge bind vars in IN()" (See slide #11) >> >> I wonder:

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Nov 30, 2015 at 10:39 PM, Michael Paquier wrote: > On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote: >> Instinctively, it seems to me that we had better return Nan for the >> new asind and acosd when being out of range for OSX, Linux will >> complain

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Michael Paquier writes: > On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote: >> Instinctively, it seems to me that we had better return Nan for the >> new asind and acosd when being out of range for OSX, Linux will >> complain about an out-of-range error so the

Re: [HACKERS] proposal: multiple psql option -c

On Thu, Nov 26, 2015 at 4:21 AM, Pavel Stehule wrote: > Attached patch per Tom Lane proposal. > > * multiple -c -f options are supported, the order of options is respected > * the statements for one -c options are executed in transactions > * Iacob's doc patch merged enum _actions {

Re: [HACKERS] Potential pointer dereference in plperl.c (caused by transforms patch)

On Sat, Nov 28, 2015 at 5:29 AM, Noah Misch wrote: > fcinfo->flinfo->fn_oid==InvalidOid implies an inline block, and those have no > arguments. If it placates Coverity, I lean toward an assert-only change: Oh, thanks. I missed this point. > --- a/src/pl/plperl/plperl.c > +++

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, Thank you for your comments. Please find attached patch addressing following comments , >- duplicate_oids error in HEAD. Check. >- a compiler warning: >pgstat.c:2898: warning: no previous prototype for ‘pgstat_reset_activityflag’ Check. >One more change you could do is

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Fri, Nov 27, 2015 at 6:33 PM, Dean Rasheed wrote: > > On 11 November 2015 at 11:45, Dean Rasheed wrote: > > Thanks for testing. I'll post an updated patch sometime soon. > > > > I finally got round to looking at this again, and here is an

[HACKERS] [PoC] Asynchronous execution again (which is not parallel)

Hello, the parallel scan became to work. So I'd like to repropose the 'asynchronous execution' or 'early execution'. In previous proposal, I had only foreign scan as workable example, but now I can use the parallel execution instead to make this distinctive from parallel execution itself. I

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote: > Instinctively, it seems to me that we had better return Nan for the > new asind and acosd when being out of range for OSX, Linux will > complain about an out-of-range error so the code is right in this > case. This is still mentioned

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Nov 30, 2015 at 11:11 PM, Tom Lane wrote: > Michael Paquier writes: >> On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote: >>> Instinctively, it seems to me that we had better return Nan for the >>> new asind and acosd when being out of

Re: [HACKERS] Some questions about the array.

The new version of the patch. On Friday 27 November 2015 17:23:35 Teodor Sigaev wrote: > 1 > Documentation isn't very informative Added example with different results. > 2 > Seems, error messages are too inconsistent. If you forbid omitting bound in > assigment then if all cases error message

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > On Mon, Nov 30, 2015 at 6:28 AM, Noah Misch wrote: > > The proposed code is short on guidance about when to put a function in > > TestLib > > versus TestBase. TestLib has no header comment. The TestBase header > > comment > > would permit, for