Re: [HACKERS] pageinspect patch, for showing tuple data

On Wed, Sep 9, 2015 at 8:39 PM, Nikolay Shaplov wrote: > В письме от 8 сентября 2015 11:53:24 Вы написали: >> Hence, instead of all those complications, why not simply introducing two >> functions that take as input the tuple data and the OID of the relation, >> returning those bytea arrays? It se

Re: [HACKERS] checkpointer continuous flushing

Hello Amit, - T1 flush=off 27480 -> 27482 :+0.0% - T1 flush=on 25214 -> 26819 :+6.3% - T2 flush=off 5050 -> 6194 : +22.6% - T2 flush=on2771 -> 6110 : +120.4% There is a clear win only in cases when sort is used with flush, apart from that using sort alone doesn't hav

[HACKERS] Small typo in timeline.h regarding the meaning of infinity for timeline history entry

Hi all, timeline.h quotes that the end point of timeline history entry means infinity when its value is 0. But that's not completely true, I think that what is meant here is InvalidXLogRecPtr: { TimeLineID tli; XLogRecPtr begin; /* inclusive */ - X

Re: [HACKERS] Use pg_rewind when target timeline was switched

On Wed, Sep 9, 2015 at 7:13 PM, Alexander Korotkov wrote: > On Wed, Sep 9, 2015 at 9:01 AM, Michael Paquier wrote: >> The code building the target history file is a duplicate of what is done >> with the source. Perhaps we could refactor that as a single routine in >> pg_rewind.c? > > > Do you mean

Re: [HACKERS] checkpointer continuous flushing

On Wed, Sep 9, 2015 at 12:12 PM, Andres Freund wrote: > On 2015-09-09 20:56:15 +0200, Fabien COELHO wrote: > > As I wrote before, FreeBSD would be a good candidate because the > > posix_fadvise seems much more reasonable than on Linux, and should be > > profitable, so it would be a pity to remove

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Thu, Sep 10, 2015 at 1:08 PM, Amit Kapila wrote: > On Thu, Sep 10, 2015 at 9:29 AM, Fujii Masao wrote: >> >> On Thu, Sep 10, 2015 at 12:49 PM, Amit Kapila >> wrote: >> > On Wed, Sep 9, 2015 at 6:43 PM, Fujii Masao >> > wrote: >> >> >> >> On Fri, Sep 4, 2015 at 4:48 PM, Amit Kapila >> >> wro

Re: [HACKERS] Parallel Seq Scan

On Thu, Sep 10, 2015 at 4:16 AM, Robert Haas wrote: > > On Wed, Sep 9, 2015 at 11:07 AM, Amit Kapila wrote: > > On Wed, Sep 9, 2015 at 11:47 AM, Haribabu Kommi < kommi.harib...@gmail.com> > > wrote: > >> With subquery, parallel scan is having some problem, please refer below. > >> > >> postgres=#

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Thu, Sep 10, 2015 at 9:29 AM, Fujii Masao wrote: > > On Thu, Sep 10, 2015 at 12:49 PM, Amit Kapila wrote: > > On Wed, Sep 9, 2015 at 6:43 PM, Fujii Masao wrote: > >> > >> On Fri, Sep 4, 2015 at 4:48 PM, Amit Kapila > >> wrote: > >> > > > > - errdetail("Could not rename \"%s\" to \"%s\": %m."

Re: [HACKERS] checkpointer continuous flushing

On Wed, Sep 9, 2015 at 2:31 PM, Fabien COELHO wrote: > > > Hello Amit, > >>> I think that we may conclude, on these run: >>> >>> (1) sorting seems not to harm performance, and may help a lot. >> >> >> I agree with first part, but about helping a lot, I am not sure > > > I'm focussing on the "sort"

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Thu, Sep 10, 2015 at 12:49 PM, Amit Kapila wrote: > On Wed, Sep 9, 2015 at 6:43 PM, Fujii Masao wrote: >> >> On Fri, Sep 4, 2015 at 4:48 PM, Amit Kapila >> wrote: >> > >> > You mean to say, just try renaming tablespace_map and don't display any >> > message whether that is successful or not-s

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Wed, Sep 9, 2015 at 6:43 PM, Fujii Masao wrote: > > On Fri, Sep 4, 2015 at 4:48 PM, Amit Kapila wrote: > > > > You mean to say, just try renaming tablespace_map and don't display any > > message whether that is successful or not-successful? > > > > I see some user inconvenience if we do this w

Re: [HACKERS] [PATCH] SQL function to report log message

David Fetter writes: > On Thu, Sep 10, 2015 at 01:32:10AM +0200, Andres Freund wrote: >> I'm not convinced. Sure, it's easy, but I by now have written the >> respective function dozens of times. Why should we force that on >> everyone? > +20 or so here, that being the number of times I recall off

Re: [HACKERS] proposal: function parse_ident

Hi 2015-09-09 21:55 GMT+02:00 Alvaro Herrera : > Pavel Stehule wrote: > > > I cannot to use current SplitIdentifierString because it is designed for > > different purpose - and it cannot to separate non identifier part. But > the > > code is simple - and will be cleaned. > > > > postgres=# selec

Re: [HACKERS] [PATCH] SQL function to report log message

2015-09-10 2:47 GMT+02:00 David Fetter : > On Thu, Sep 10, 2015 at 01:32:10AM +0200, Andres Freund wrote: > > On 2015-09-09 18:27:51 -0400, Robert Haas wrote: > > > On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar > wrote: > > > > Sure, it’s a clear fact that, we can implement this function > > > >

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

On 2015-09-04 23:35:42 +0100, Simon Riggs wrote: > This looks OK. You saw that I was proposing to solve this problem a > different way ("Summary of plans to avoid the annoyance of Freezing"), > suggesting that we wait for a few CFs to see if a patch emerges for that - > then fall back to this patch

Re: [HACKERS] Do Layered Views/Relations Preserve Sort Order ?

On 9/9/15 7:44 PM, David G. Johnston wrote: On Wed, Sep 9, 2015 at 7:53 PM, Charles Sheridan >wrote: Hi All, When there are several views defined on top of each other, are SELECTs on views that do not specify a SORT order guaranteed to preserve the cum

Re: [HACKERS] [PATCH] SQL function to report log message

On Thu, Sep 10, 2015 at 01:32:10AM +0200, Andres Freund wrote: > On 2015-09-09 18:27:51 -0400, Robert Haas wrote: > > On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar > > wrote: > > > Sure, it’s a clear fact that, we can implement this function > > > with RAISE statements. > > > > Given that, I sug

Re: [HACKERS] Do Layered Views/Relations Preserve Sort Order ?

On Wed, Sep 9, 2015 at 7:53 PM, Charles Sheridan wrote: > Hi All, > > When there are several views defined on top of each other, are SELECTs on > views that do not specify a SORT order guaranteed to preserve the > cumulative sort order of the lower-level views ? > > Is the answer true for any arb

[HACKERS] Do Layered Views/Relations Preserve Sort Order ?

Hi All, When there are several views defined on top of each other, are SELECTs on views that do not specify a SORT order guaranteed to preserve the cumulative sort order of the lower-level views ? Is the answer true for any arbitrarily large set of layered views? Is the answer the same if th

Re: [HACKERS] [PATCH] SQL function to report log message

On 2015-09-09 18:27:51 -0400, Robert Haas wrote: > On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar wrote: > > Sure, it’s a clear fact that, we can implement this function with RAISE > > statements. > > Given that, I suggest we just forget the whole thing. I'm not convinced. Sure, it's easy, but I

Re: [HACKERS] [PATCH] SQL function to report log message

On 9/9/15 5:27 PM, Robert Haas wrote: Sure, it’s a clear fact that, we can implement this function with RAISE >statements. Given that, I suggest we just forget the whole thing. Except that you can't use a variable to control the log level in a plpgsql RAISE, so then you end up with a CASE sta

Re: [HACKERS] Parallel Seq Scan

On Wed, Sep 9, 2015 at 11:07 AM, Amit Kapila wrote: > On Wed, Sep 9, 2015 at 11:47 AM, Haribabu Kommi > wrote: >> With subquery, parallel scan is having some problem, please refer below. >> >> postgres=# explain analyze select * from test01 where kinkocord not in >> (select kinkocord from test02

Re: [HACKERS] [PATCH] SQL function to report log message

On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar wrote: > I am admitting here that, I don’t know the real use case behind this > proposal in our TODO list. I thought, having ereport wrapper at SQL level, > gives a default debugging behavior for the end users, and this is the only > real use case I se

Re: [HACKERS] Modernizing contrib/tablefunc

On 09/09/2015 03:03 PM, David Fetter wrote: > Folks, > > While doing some research for the upcoming (UN)PIVOT proposal, I > noticed that there were some hairy and no-longer-needed bits in the > regression tests for tablefunc, which I have shaved off with the > attached patch. > > What say? Is th

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

On 9/9/15 12:03 PM, Oskari Saarenmaa wrote: andrew=# select '[1]'::jsonb || '{"a":"b"}'; ?column? - [1, {"a": "b"}] It looks wrong, but I'm not sure what's right in that case. I think it'd make sense to just restrict concatenation to object || object, arr

[HACKERS] Modernizing contrib/tablefunc

Folks, While doing some research for the upcoming (UN)PIVOT proposal, I noticed that there were some hairy and no-longer-needed bits in the regression tests for tablefunc, which I have shaved off with the attached patch. What say? Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415

Re: [HACKERS] Raising our compiler requirements for 9.6

On 2015-08-27 11:31:44 -0400, Tom Lane wrote: > Needs a bit of copy-editing in places, but +1 overall. Heres a slightly expanded version of this. I tried to do some of the copy-editing, but I'm sure a look from a native speaker won't hurt. Greetings, Andres Freund diff --git a/doc/src/sgml/sourc

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

Robert Haas wrote: > I think the problem we should be trying to solve is: Given a set > of server IPs, connect to one that is up. > > I believe this comes up in several different scenarios. > > Example #1: [single server; changing IP address gracefully] > > Example #2: [xDB/BDR client uses local

Re: [HACKERS] checkpointer continuous flushing

It would replace what is currently an array. It'd still be one afterwards. [...] extract/reinsert is actually O(1). Hm, strange. I probably did not understood at all the heap structure you're suggesting. No big deal. [...] Why would a heap as I've described it require that? Hmmm... The

Re: [HACKERS] proposal: function parse_ident

Pavel Stehule wrote: > I cannot to use current SplitIdentifierString because it is designed for > different purpose - and it cannot to separate non identifier part. But the > code is simple - and will be cleaned. > > postgres=# select * from parse_ident('"AHOJ".NAZDAR[]'::text); > ┌─

Re: [HACKERS] checkpointer continuous flushing

As I wrote before, FreeBSD would be a good candidate because the posix_fadvise seems much more reasonable than on Linux, and should be profitable, so it would be a pity to remove it. Why do you think it's different on fbsd? Also, why is it unreasonable that DONNEED removes stuff from the cac

Re: [HACKERS] checkpointer continuous flushing

On 2015-09-09 21:29:12 +0200, Fabien COELHO wrote: > >Imagine a binaryheap.h style heap over a structure like (tablespaceid, > >progress, progress_inc, nextbuf) where the comparator compares the progress. > > It would replace what is currently an array. It'd still be one afterwards. > The balanc

Re: [HACKERS] checkpointer continuous flushing

Hello Andres, Wouldn't it be just as easy to put this logic into the checkpointing code? Not sure it would simplify anything, because the checkpointer currently knows about buffers but flushing is about files, which are hidden from view. It'd not really simplify things, but it'd keep it loc

Re: [HACKERS] checkpointer continuous flushing

On 2015-09-09 20:56:15 +0200, Fabien COELHO wrote: > As I wrote before, FreeBSD would be a good candidate because the > posix_fadvise seems much more reasonable than on Linux, and should be > profitable, so it would be a pity to remove it. Why do you think it's different on fbsd? Also, why is it u

[HACKERS] Latent cache flush hazard in RelationInitIndexAccessInfo

Some stuff Salesforce has been doing turned up the fact that RelationInitIndexAccessInfo is not safe against a relcache flush on its target index. Specifically, the failure goes like this: * RelationInitIndexAccessInfo loads up relation->rd_indextuple. * Within one of the subsequent catalog fetc

Re: [HACKERS] checkpointer continuous flushing

(3) posix_fadvise on Linux is a bad idea... the good news is that it is not needed there:-) How good or bad an idea it is on other system is an open question... I don't know what is the best way to verify that, if some body else has access to such a m/c, please help to get that verifie

[HACKERS] 答复：[HACKERS] 答复：[HACKERS] 答复：[HACKERS] about fsync in CLOG buffer write

HI,   Sorry, it's my misunderstand.    I don't read seriously SlruSelectLRUPage before.   /* See if page already has a buffer assigned */   for (slotno = 0; slotno < shared->num_slots; slotno++)   {    if (shared->page_number[slotno] == pageno && shared->page_status[slotno] != SLRU_PAGE_EMPTY)

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

09.09.2015, 18:53, Andrew Dunstan kirjoitti: On 09/08/2015 09:54 AM, Andrew Dunstan wrote: On 09/05/2015 02:47 AM, Oskari Saarenmaa wrote: There was a long thread about concatenating jsonb objects to each other, but that discussion didn't touch concatenating other types. Currently jsonb_concat

Re: [HACKERS] [PATCH v2] GSSAPI encryption support

Michael Paquier writes: > On Wed, Sep 9, 2015 at 4:12 AM, Robbie Harwood wrote: >> Michael Paquier writes: >> As promised, here's a V2 to address your issues with comments. I >> haven't heard back on the issues you found in testing, so no other >> changes are present. > > Well, the issue is stil

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

On 09/08/2015 09:54 AM, Andrew Dunstan wrote: On 09/05/2015 02:47 AM, Oskari Saarenmaa wrote: There was a long thread about concatenating jsonb objects to each other, but that discussion didn't touch concatenating other types. Currently jsonb_concat always just returns the other argument if

Re: [HACKERS] DBT-3 with SF=20 got failed

On 09/09/2015 03:55 PM, Robert Haas wrote: On Tue, Sep 8, 2015 at 5:02 PM, Tomas Vondra wrote: Also, I'm not sure what other places do you have in mind (could you list some examples?) but I'd bet we limit the allocation to 1GB because of the palloc() limit and not because of fear of over-estima

Re: [HACKERS] [PATCH] SQL function to report log message

HI Robert, On Wed, Sep 9, 2015 at 8:30 PM, Robert Haas wrote: > On Wed, Jul 22, 2015 at 9:56 PM, dinesh kumar > wrote: > >> The real question is why the existing functionality in plpgsql isn't > >> sufficient. Somebody who wants a "log from SQL" function can easily > >> write a simple plpgsql

Re: [HACKERS] [GENERAL] Feature Request: bigtsvector

On Wed, Sep 9, 2015 at 06:14:28PM +0300, Ildus Kurbangaliev wrote: > On Wed, 9 Sep 2015 10:52:02 -0400 > Bruce Momjian wrote: > > > On Wed, Jun 17, 2015 at 07:58:21AM +0200, CPT wrote: > > > Hi all; > > > > > > We are running a multi-TB bioinformatics system on PostgreSQL and > > > use a denorm

Re: [HACKERS] [GENERAL] Feature Request: bigtsvector

On Wed, 9 Sep 2015 10:52:02 -0400 Bruce Momjian wrote: > On Wed, Jun 17, 2015 at 07:58:21AM +0200, CPT wrote: > > Hi all; > > > > We are running a multi-TB bioinformatics system on PostgreSQL and > > use a denormalized schema in > > places with a lot of tsvectors aggregated together for centrali

Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] 答复：[HACKERS] 答复：[HACKERS] about fsync in CLOG buffer write

On 2015-09-09 10:46:47 -0400, Robert Haas wrote: > Well, if you're filling ~1 clog page per second, you're doing ~1 fsync > per second too. Or if you are not, then you are thrashing the > progressively smaller and smaller number of clean slots ever-harder > until no clean pages remain and you're f

Re: [HACKERS] Parallel Seq Scan

On Wed, Sep 9, 2015 at 8:09 PM, Robert Haas wrote: > > On Wed, Sep 9, 2015 at 2:17 AM, Haribabu Kommi wrote: > > And also regarding the number of workers (16) that is shown in the > > explain analyze plan are not actually allotted because the in my > > configuration i set the max_worker_process a

Re: [HACKERS] Parallel Seq Scan

On Wed, Sep 9, 2015 at 11:47 AM, Haribabu Kommi wrote: > > With subquery, parallel scan is having some problem, please refer below. > > > postgres=# explain analyze select * from test01 where kinkocord not in > (select kinkocord from test02 where tenpocord = '001'); > ERROR: badly formatted node

Re: [HACKERS] Counting lines correctly in psql help displays

On 09/09/2015 10:27 AM, Tom Lane wrote: Andrew Dunstan writes: On 09/05/2015 12:55 PM, Tom Lane wrote: Or we could just give up and replace the counts by INT_MAX, forcing use of the pager unless you've turned it off. All of those outputs are long enough now that it's hard to believe there a

Re: [HACKERS] [PATCH] SQL function to report log message

On Wed, Jul 22, 2015 at 9:56 PM, dinesh kumar wrote: >> The real question is why the existing functionality in plpgsql isn't >> sufficient. Somebody who wants a "log from SQL" function can easily >> write a simple plpgsql function that does exactly what they want, >> with no more or fewer bells-n

Re: [HACKERS] Autonomous Transaction is back

On Wed, Sep 9, 2015 at 9:04 AM, Robert Haas wrote: > On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote: >> What design principle(s) have you been using to decide how autonomous >> transactions should behave? > > I have to admit to a complete lack of principle. I'm quite frightened > of what this

Re: [HACKERS] [GENERAL] Feature Request: bigtsvector

On Wed, Jun 17, 2015 at 07:58:21AM +0200, CPT wrote: > Hi all; > > We are running a multi-TB bioinformatics system on PostgreSQL and > use a denormalized schema in > places with a lot of tsvectors aggregated together for centralized > searching. This is > very important to the performance of the

Re: [HACKERS] checkpointer continuous flushing

On Tue, Sep 8, 2015 at 11:31 PM, Amit Kapila wrote: >> (3) posix_fadvise on Linux is a bad idea... the good news is that it >> is not needed there:-) How good or bad an idea it is on other system >> is an open question... > > I don't know what is the best way to verify that, if some body e

[HACKERS] Re: [HACKERS] Re: [HACKERS] 答复：[HACKERS] 答复：[HACKERS] about fsync in CLOG buffer write

On Wed, Sep 9, 2015 at 10:35 AM, Tom Lane wrote: > Robert Haas writes: >> ... How often such a workload actually has to replace a *dirty* clog >> buffer obviously depends on how often you checkpoint, but if you're >> getting ~28k TPS you can completely fill 32 clog buffers (1 million >> transacti

Re: [HACKERS] Parallel Seq Scan

On Wed, Sep 9, 2015 at 2:17 AM, Haribabu Kommi wrote: > And also regarding the number of workers (16) that is shown in the > explain analyze plan are not actually allotted because the in my > configuration i set the max_worker_process as 8 only. I feel the plan > should show the allotted workers n

Re: [HACKERS] Re: [HACKERS] 答复：[HACKERS] 答复：[HACKERS] about fsync in CLOG buffer write

Robert Haas writes: > ... How often such a workload actually has to replace a *dirty* clog > buffer obviously depends on how often you checkpoint, but if you're > getting ~28k TPS you can completely fill 32 clog buffers (1 million > transactions) in less than 40 seconds, and you're probably not >

Re: [HACKERS] Counting lines correctly in psql help displays

Andrew Dunstan writes: > On 09/05/2015 12:55 PM, Tom Lane wrote: >> Or we could just give up and replace the counts by INT_MAX, forcing use >> of the pager unless you've turned it off. All of those outputs are long >> enough now that it's hard to believe there are any common screen layouts >> whe

[HACKERS] Re: [HACKERS] 答复：[HACKERS] 答复：[HACKERS] about fsync in CLOG buffer write

On Tue, Sep 8, 2015 at 2:28 PM, Andres Freund wrote: > On 2015-09-08 15:58:26 +0800, 周正中(德歌) wrote: >> postgres@digoal-> cat 7.sql >> select txid_current(); >> >> postgres@digoal-> pgbench -M prepared -n -r -P 1 -f ./7.sql -c 1 -j 1 -T >> 10 >> About 32K tps. >> progress: 240.0 s, 31164.4 tps

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

> > > \x doesn't exactly rotate it either. \x puts the column headers down > the side instead of across the top, but it doesn't put the rows across > the top instead of down the side. Rather, each row is listed in a > separate chunk. true, it is rotation per one row. I was wrong. > This featu

Re: [HACKERS] Autonomous Transaction is back

On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote: > What design principle(s) have you been using to decide how autonomous > transactions should behave? I have to admit to a complete lack of principle. I'm quite frightened of what this is going to need from the lock manager, and I'm trying to wri

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

On Tue, Sep 8, 2015 at 4:58 PM, Pavel Stehule wrote: > 2015-09-08 22:55 GMT+02:00 Daniel Verite : >> >> Pavel Stehule wrote: >> >> > rotate ~ sounds like transpose matrix, what is not true in this case. > > for me the relation rotation is exactly what \x does \x doesn't exactly rotate it

Re: [HACKERS] DBT-3 with SF=20 got failed

On Tue, Sep 8, 2015 at 5:02 PM, Tomas Vondra wrote: > Also, I'm not sure what other places do you have in mind (could you list > some examples?) but I'd bet we limit the allocation to 1GB because of the > palloc() limit and not because of fear of over-estimates. I don't really think those two thi

Re: [HACKERS] Dependency between bgw_notify_pid and bgw_flags

On Wed, Sep 9, 2015 at 8:14 AM, Ashutosh Bapat wrote: > PFA patch with improved test module and fix for a bug. > > bgworker_sigusr1_handler() should set the latch when set_latch_on_sigusr1 is > true, similar to procsignal_sigusr1_handler(). Without this fix, if a > background worker without DATABA

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Fri, Sep 4, 2015 at 4:48 PM, Amit Kapila wrote: > On Thu, Sep 3, 2015 at 6:07 PM, Fujii Masao wrote: >> >> On Tue, Aug 4, 2015 at 12:15 PM, Amit Kapila >> wrote: >> > On Mon, Aug 3, 2015 at 7:44 PM, Fujii Masao >> > wrote: >> >> ISTM that we can >> >> see that the online backup mode has alre

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund wrote: > My vote is that we should try to get freeze maps into 9.6 - that seems > more realistic given that we have a patch right now. Yes, it might end > up being superflous churn, but it's rather localized. I think around > we've put off significant

Re: [HACKERS] pgsql: Improve logging of TAP tests.

Noah, * Noah Misch (n...@leadboat.com) wrote: > On Tue, Sep 08, 2015 at 02:58:36PM -0400, Stephen Frost wrote: > > * Andrew Dunstan (and...@dunslane.net) wrote: > > > Improve logging of TAP tests. > > > > [...] > > > > This broke 'make check' for REL9_4_STABLE with --enable-tap-tests > > because

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On Sun, Sep 6, 2015 at 8:25 AM, Andres Freund wrote: > On 2015-08-10 07:03:02 +0100, Simon Riggs wrote: >> I was previously a proponent of (2) as a practical way forwards, but my >> proposal here today is that we don't do anything further on 2) yet, and >> seek to make progress on 5) instead. >> >

Re: [HACKERS] Dependency between bgw_notify_pid and bgw_flags

On Wed, Sep 2, 2015 at 2:02 AM, Robert Haas wrote: > On Mon, Aug 31, 2015 at 8:01 AM, Ashutosh Bapat > wrote: > >> Thanks. It needs testing though to see if it really works as > >> intended. Can you look into that? > > > > PFA the patch containing your code changes + test module. See if that >

Re: [HACKERS] pageinspect patch, for showing tuple data

В письме от 8 сентября 2015 11:53:24 Вы написали: > On Sat, Sep 5, 2015 at 1:05 AM, Nikolay Shaplov wrote: > > В письме от 4 сентября 2015 14:58:29 пользователь Michael Paquier написал: > > > Documentation is missing, that would be good to have to understand what > > > each function is intended to

Re: [HACKERS] Waits monitoring

On Tue, Sep 8, 2015 at 8:01 PM, Robert Haas wrote: > On Mon, Sep 7, 2015 at 7:33 AM, Ildus Kurbangaliev > wrote: > >> > Ildus, could you please review Amit & Robert's patch? > >> [1] - > >> > http://www.postgresql.org/message-id/caa4ek1kdec1tm5ya9gkv85vtn4qqsrxzkjru-tu70g_tl1x...@mail.gmail.com

Re: [HACKERS] Use pg_rewind when target timeline was switched

On Wed, Sep 9, 2015 at 9:01 AM, Michael Paquier wrote: > > > On Wed, Sep 9, 2015 at 3:27 AM, Alexander Korotkov > wrote: > >> On Tue, Sep 8, 2015 at 10:28 AM, Michael Paquier >> wrote: >> >>> I am planning to do as well a detailed code review rather soon. >>> >> >> Good, thanks. >> > > When test

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

On 2015/07/10 18:40, Etsuro Fujita wrote: > To save cycles, I modified create_foreignscan_plan so that it detects > whether any system columns are requested if scanning a base relation. > Also, I revised other code there a little bit. Attached is an updated version of the patch. The previous vers

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

On Wed, Sep 9, 2015 at 10:22 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Wed, Sep 9, 2015 at 8:36 AM, Pavel Stehule > wrote: > >> >>> Please find attached v4. >>> >> >> It is better >> > > One important thing to notice, and probably deserves a code comment, that > any modif

Re: [HACKERS] checkpointer continuous flushing

Hello Amit, I think that we may conclude, on these run: (1) sorting seems not to harm performance, and may help a lot. I agree with first part, but about helping a lot, I am not sure I'm focussing on the "sort" dimension alone, that is I'm comparing the average tps performance with sortin

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

Two notices: > > 1. The communication mechanism can be used more wide, than only for this > purpose. We can introduce a SendInfoHook - and it can be used for any > customer probes - memory, cpu, ... > Not sure if for CPU you can get any more insight than an external tool like top(1) will provide.

Re: [HACKERS] pgbench progress with timestamp

In the sgml, second should be plural in 'intead of the number of second since the'. And 'intead' should be 'instead'. Ok. --progress-timestamp use a Unix-like epoch timestamp for progress reporting but that is getting pretty long. Indeed. I've done: --progress-timestamp use Unix

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

On Wed, Sep 9, 2015 at 8:36 AM, Pavel Stehule wrote: > >> Please find attached v4. >> > > It is better > One important thing to notice, and probably deserves a code comment, that any modification of the slot fields done by the info sender backend must be done before actually sending the message

Re: [HACKERS] Odd/undocumented precedence of concatenation operator

> > It is expected, and documented. (It's also different in 9.5, see > > http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=c6b3c939b7e0f1d35f4ed4996e71420a993810d2 > ) > Ah, thanks! > > If nothing else, it seems that the concatenation operator should be > listed > > on the opera

Re: [HACKERS] proposal: function parse_ident

next iteration - fixed bug in parsing UTF8 chars, enhanced error messages. Regards Pavel diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml new file mode 100644 index b3b78d2..75ea33a *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml *** *** 1707,1712 --- 1707,1