Re: [HACKERS] Erroneous cost estimation for nested loop join

kawami...@tkl.iis.u-tokyo.ac.jp writes: > - cost parameter calibration: random_page_cost = 92.89 TBH, you lost me there already. I know of no hardware on which that would be a sane depiction of reality, so I think you've probably overfitted the model to some particular case it was already

Re: [HACKERS] Some questions about the array.

2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev : > On Monday 09 November 2015 13:50:20 Pavel Stehule wrote: > > New symbols increase a complexity of our code and our documentation. > > > > If some functionality can be implemented via functions without > performance > >

Re: [HACKERS] Some questions about the array.

2015-11-09 13:50 GMT+01:00 Pavel Stehule : > > > 2015-11-09 13:32 GMT+01:00 YUriy Zhuravlev : > >> On Monday 09 November 2015 13:29:30 you wrote: >> > It is ugly, but you can wrap it to function - so still I don't see any >> > reason, why it is

Re: [HACKERS] Some questions about the array.

2015-11-09 13:07 GMT+01:00 YUriy Zhuravlev : > On Monday 09 November 2015 12:48:54 you wrote: > > I am sorry - it is looking pretty obscure. Really need this feature? > > IMHO yes. > Now for write: array[~2:~-2] you need like: > array[array_lower(array, 1)+3:

Re: [HACKERS] Some questions about the array.

On 11/9/15, YUriy Zhuravlev wrote: > On Monday 09 November 2015 12:48:54 you wrote: >> I am sorry - it is looking pretty obscure. Really need this feature? > > IMHO yes. > Now for write: array[~2:~-2] you need like: > array[array_lower(array, 1)+3: array_upper(array,

Re: [HACKERS] Some questions about the array.

2015-11-09 13:32 GMT+01:00 YUriy Zhuravlev : > On Monday 09 November 2015 13:29:30 you wrote: > > It is ugly, but you can wrap it to function - so still I don't see any > > reason, why it is necessary > For example, I'm writing a lot of queries by hands... > This

Re: [HACKERS] Some questions about the array.

On Monday 09 November 2015 13:29:30 you wrote: > It is ugly, but you can wrap it to function - so still I don't see any > reason, why it is necessary For example, I'm writing a lot of queries by hands... This functionality is available in many languages and it's just convenient. Of course it is

Re: [HACKERS] Some questions about the array.

2015-11-09 13:38 GMT+01:00 YUriy Zhuravlev : > On Monday 09 November 2015 04:33:28 you wrote: > > You can write it as a separate function instead of changing current > syntax. > I do not think, because we have a multi-dimensional arrays. > And why we have [:] syntax

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

2015-11-05 7:24 GMT+01:00 Catalin Iacob : > On Wed, Nov 4, 2015 at 10:12 AM, Pavel Stehule > wrote: > > It helped me lot of, thank you > > Welcome, I learned quite some from the process as well. > > >> > >> > >> There's just the doc part left

Re: [HACKERS] Some questions about the array.

On Monday 09 November 2015 13:50:20 Pavel Stehule wrote: > New symbols increase a complexity of our code and our documentation. > > If some functionality can be implemented via functions without performance > impacts, we should not to create new operators or syntax - mainly for > corner use

Re: [HACKERS] Some questions about the array.

On Monday 09 November 2015 04:33:28 you wrote: > You can write it as a separate function instead of changing current syntax. I do not think, because we have a multi-dimensional arrays. And why we have [:] syntax now? -- YUriy Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2015-11-09 11:54:59 -0500, Jesper Pedersen wrote: > Hi, > > On 11/06/2015 03:47 PM, Jesper Pedersen wrote: > >>Did you initdb between tests? Pgbench -i? Restart the database? > > > >I didn't initdb / pgbench -i between the tests, so that it is likely it. > > > > Each graph has a full initdb +

[HACKERS] Multixact slru doesn't don't force WAL flushes in SlruPhysicalWritePage()

Hi, By happenstance I just had slru.h open after lunch and noticed the following comment: /* * Optional array of WAL flush LSNs associated with entries in the SLRU * pages. If not zero/NULL, we must flush WAL before writing pages (true * for pg_clog, false for

[HACKERS] storage/buffer/README docs about buffer replacement are out of date

Hi, $subject contains: > The "clock hand" is a buffer index, nextVictimBuffer, that moves circularly > through all the available buffers. nextVictimBuffer is protected by the > buffer_strategy_lock. > > The algorithm for a process that needs to obtain a victim buffer is: > > 1. Obtain

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

Adam Brightwell writes: >>> Need to bump this #define? If you didn't get the error that this is >>> supposed to throw, perhaps there's a bug somewhere worth investigating. > Whoops! It must be getting late... updated patch attached. I'm with Alvaro: the most

Re: [HACKERS] CustomScan support on readfuncs.c

> On Sat, Nov 7, 2015 at 6:38 AM, Kouhei Kaigai wrote: > > Are you suggesting to pass the object name on software build time? > > Yes. That's what test_shm_mq and worker_spi already do: > > sprintf(worker.bgw_library_name, "test_shm_mq"); > OK, I ripped out the

Re: [HACKERS] clearing opfuncid vs. parallel query

On Thu, Oct 22, 2015 at 05:14:29PM -0400, Robert Haas wrote: > On Thu, Oct 22, 2015 at 5:09 PM, Tom Lane wrote: > > Robert Haas writes: > >> Despite everybody's best efforts, we mess this up more than is really > >> desirable. Commit

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

>> @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void) >> AuthIdRelationId); >> load_critical_index(AuthMemMemRoleIndexId, >> AuthMemRelationId); >> +

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

On 2015-11-09 23:38:57 -0500, Adam Brightwell wrote: > >> @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void) > >> AuthIdRelationId); > >> load_critical_index(AuthMemMemRoleIndexId, > >>

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

On 2015/10/29 23:22, Syed, Rahila wrote: > > Please find attached an updated patch. > Thanks for the v6. A few quick comments: - duplicate_oids error in HEAD. - a compiler warning: pgstat.c:2898: warning: no previous prototype for ‘pgstat_reset_activityflag’ To fix that use void for empty

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

>> >> #define NUM_CRITICAL_SHARED_INDEXES 5/* fix if you change list >> >> above */ >> >> >> > >> > Need to bump this #define? If you didn't get the error that this is >> > supposed to throw, perhaps there's a bug somewhere worth investigating. >> >> Hmm... I thought that I had, are you

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

On Fri, Nov 6, 2015 at 8:08 PM, Peter Geoghegan wrote: > On Wed, Aug 19, 2015 at 7:24 PM, Peter Geoghegan wrote: > > I'll start a new thread for this, since my external sorting patch has > > now evolved well past the original "quicksort with spillover" > >

Re: [HACKERS] Multixid hindsight design

On Mon, Nov 9, 2015 at 2:02 AM, Craig Ringer wrote: > On 25 June 2015 at 00:52, Robert Haas wrote: >> I agree that we can do much better at testing than we traditionally >> have done, and I think pretty much everyone in the room for the >> developer

Re: [HACKERS] eXtensible Transaction Manager API

On Sun, Nov 8, 2015 at 6:35 PM, Michael Paquier wrote: > Sure. Now imagine that the pg_twophase entry is corrupted for this > transaction on one node. This would trigger a PANIC on it, and > transaction would not be committed everywhere. If the database is corrupted,

Re: [HACKERS] Minor comment improvement to create_foreignscan_plan

On Mon, Nov 9, 2015 at 5:34 AM, Etsuro Fujita wrote: > Here is a small patch to update an comment in create_foreignscan_plan; > add fdw_recheck_quals to the list of expressions that need the > replace_nestloop_params processing. I should have updated the comment >

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

On 09.11.2015 17:41, Tom Lane wrote: Kevin Grittner writes: On Monday, November 9, 2015 9:37 AM, Robert Haas wrote: That doesn't seem like enough consensus to commit this patch, which would change everything to +/-infinity. That particular choice

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

Hi 2015-11-05 22:23 GMT+01:00 Robert Haas : > On Thu, Nov 5, 2015 at 3:53 PM, Catalin Iacob > wrote: > > On Thu, Nov 5, 2015 at 5:27 PM, Robert Haas > wrote: > >>> I wrote some text. But needs some work of native speaker. >

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

On Mon, Nov 9, 2015 at 6:31 PM, Pavel Stehule wrote: > merged your patch So, I just that tested version 08 is the same as the previous patch + my change and I already tested that on Python 2.4, 2.5, 2.6, 2.7 and 3.5. All previous comments addressed so I'll mark this

Re: [HACKERS] Some questions about the array.

2015-11-09 17:55 GMT+01:00 Alexander Korotkov : > On Mon, Nov 9, 2015 at 4:53 PM, Pavel Stehule > wrote: > >> 2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev : >> >>> On Monday 09 November 2015 13:50:20 Pavel Stehule

Re: [HACKERS] Multixid hindsight design

Robert Haas writes: > On Mon, Nov 9, 2015 at 2:02 AM, Craig Ringer wrote: >> Something that'd really help with that, IMO, would be weakening the >> requirement that everything be C or be core Perl. Instead require that >> configure detect whether or

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

Adam Brightwell wrote: > @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void) > AuthIdRelationId); > load_critical_index(AuthMemMemRoleIndexId, > AuthMemRelationId); > +

Re: [HACKERS] can we add SKIP LOCKED to UPDATE?

On Mon, Nov 9, 2015 at 9:06 AM, Tom Lane wrote: > =?GBK?B?tcK45w==?= writes: >>PostgreSQL 9.5 added skip locked to select for update to improve >> concurrency performance, but why not add it to update sql? > > Seems like you'd have unpredictable results

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

2015-11-09 19:21 GMT+01:00 Catalin Iacob : > On Mon, Nov 9, 2015 at 6:31 PM, Pavel Stehule > wrote: > > merged your patch > > So, I just that tested version 08 is the same as the previous patch + > my change and I already tested that on Python

Re: [HACKERS] can we add SKIP LOCKED to UPDATE?

On 9 November 2015 at 17:06, Tom Lane wrote: > =?GBK?B?tcK45w==?= writes: > >PostgreSQL 9.5 added skip locked to select for update to improve > concurrency performance, but why not add it to update sql? > > Seems like you'd have unpredictable results from

[HACKERS] pg_receivexlog: spurious error message connecting to 9.3

Hi, I was testing the compatibility of pg_receivexlog with the previous PostgreSQL versions and I've discovered that in 9.5 and 9.6, although being compatible with 9.3, it prints an ugly but harmless error message. $ 9.5/bin/pg_receivexlog -D /tmp/testx -v -p 5493 *pg_receivexlog: could not

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

On 11/08/2015 11:17 PM, Craig Ringer wrote: > On 9 November 2015 at 12:40, Adam Brightwell > wrote: >> Hi All, >> >> While working on an auth hook, I found that I was unable to access the >> pg_shseclabel system table while processing the hook. I discovered >>

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

2015-11-09 16:46 GMT+01:00 Catalin Iacob : > On Mon, Nov 9, 2015 at 2:58 PM, Pavel Stehule > wrote: > > I needed to understand the support for Python 3.5. > > > > The patch with the fix is attached regress tests 3.5 Python > > I wanted to type a

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

On Sat, Nov 7, 2015 at 9:47 AM, Vitaly Burovoy wrote: > I'd like to raise a topic about extracting fields from infinite > timestamps, so much more that it is mentioned in the TODO list: > "Determine how to represent date/time field extraction on infinite > timestamps". >

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

On Mon, Nov 9, 2015 at 2:58 PM, Pavel Stehule wrote: > I needed to understand the support for Python 3.5. > > The patch with the fix is attached regress tests 3.5 Python I wanted to type a reply this morning to explain and then I noticed there's another file (_0.out) for

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Sat, Nov 7, 2015 at 5:42 PM, Greg Stark wrote: > On Fri, Nov 6, 2015 at 4:54 AM, Ashutosh Bapat > wrote: >> PFA patch to get data sorted from the foreign server (postgres_fdw) >> according to the pathkeys useful for merge join. > > An idle

[HACKERS] Re: [COMMITTERS] pgsql: Modify tqueue infrastructure to support transient record types.

On Mon, Nov 9, 2015 at 4:06 AM, Amit Kapila wrote: > On Sat, Nov 7, 2015 at 3:29 AM, Robert Haas wrote: >> Modify tqueue infrastructure to support transient record types. > > I am getting below compiler warning on Windows: > tqueue.c(662): warning

Re: [HACKERS] Some questions about the array.

On Mon, Nov 9, 2015 at 4:53 PM, Pavel Stehule wrote: > 2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev : > >> On Monday 09 November 2015 13:50:20 Pavel Stehule wrote: >> > New symbols increase a complexity of our code and our documentation. >> > >>

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Hi, On 11/06/2015 03:47 PM, Jesper Pedersen wrote: Did you initdb between tests? Pgbench -i? Restart the database? I didn't initdb / pgbench -i between the tests, so that it is likely it. Each graph has a full initdb + pgbench -i cycle now. I know, I have a brown paper bag somewhere.

Re: [HACKERS] CustomScan support on readfuncs.c

On Sat, Nov 7, 2015 at 6:38 AM, Kouhei Kaigai wrote: > Are you suggesting to pass the object name on software build time? Yes. That's what test_shm_mq and worker_spi already do: sprintf(worker.bgw_library_name, "test_shm_mq"); > If so, it may load incorrect

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

On Monday, November 9, 2015 9:37 AM, Robert Haas wrote: > On Sat, Nov 7, 2015 at 9:47 AM, Vitaly Burovoy > wrote: >> I'd like to raise a topic about extracting fields from infinite >> timestamps, so much more that it is mentioned in the TODO

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

> On Mon, Nov 9, 2015 at 8:22 AM, Kevin Grittner wrote: >> My first choice for other things would be NaN, but throwing an >> error instead would be OK. On Monday, November 9, 2015 10:41 AM, Tom Lane wrote: > What about returning NULL for the ill-defined

[HACKERS] can we add SKIP LOCKED to UPDATE?

HI, PostgreSQL 9.5 added skip locked to select for update to improve concurrency performance, but why not add it to update sql? this is an application case, some body will update a tuple at the same time, so the RT for waiter is big, I use function and select for update nowait or

Re: [HACKERS] can we add SKIP LOCKED to UPDATE?

=?GBK?B?tcK45w==?= writes: >PostgreSQL 9.5 added skip locked to select for update to improve > concurrency performance, but why not add it to update sql? Seems like you'd have unpredictable results from the update then. regards, tom lane -- Sent

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

I was unaware that we had +- infinity for numeric. select pg_typeof(extract(epoch from current_date)); pg_typeof -- double precision Given that null is a "special value that is used to indicate the absence of any data value" and that attributes like month or day-of-week will

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

Ildus Kurbangaliev wrote: > Thanks for the review. I've attached a new version of SLRU patch. I've > removed add_postfix and fixed EXEC_BACKEND case. Thanks. Please do not use "committs" in commit_ts.c; people didn't like the abbreviated name without the underscore. But then, why are we

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Fri, Nov 6, 2015 at 2:03 PM, Kevin Grittner wrote: > Has anyone taken a close look at what happens if the two sides of > the merge join have different implementations of the same collation > name? Is there anything we should do to defend against the > problem? The issue of

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Sat, Nov 7, 2015 at 12:07 PM, Corey Huinker wrote: > Sorry to barge in late, but I was wondering if what we've learned with this > patch can be applied to the case of asserting a sort order on a query > returning from dblink(). Nope. Sorry to the bearer of bad news,

Re: [HACKERS] Parallel Seq Scan

On Fri, Nov 6, 2015 at 10:13 AM, Robert Haas wrote: > > On Thu, Nov 5, 2015 at 10:49 PM, Amit Kapila wrote: > > On Thu, Nov 5, 2015 at 11:54 PM, Robert Haas wrote: > >> I was thinking about this idea: > >> > >> 1. Add a

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

Kevin Grittner writes: > On Monday, November 9, 2015 9:37 AM, Robert Haas > wrote: >> That doesn't seem like enough consensus to commit this patch, which >> would change everything to +/-infinity. That particular choice >> wouldn't bother me much, but

Re: [HACKERS] eXtensible Transaction Manager API

On 9 November 2015 at 18:46, Robert Haas wrote: > > I am aware of the fact > > that by definition PREPARE TRANSACTION ensures that a transaction will > > be committed with COMMIT PREPARED, just trying to see any corner cases > > with the approach proposed. The DTM

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

> On Nov 9, 2015, at 7:56 PM, Alvaro Herrera wrote: > > Ildus Kurbangaliev wrote: > >> Thanks for the review. I've attached a new version of SLRU patch. I've >> removed add_postfix and fixed EXEC_BACKEND case. > > Thanks. > > Please do not use "committs" in

Re: [HACKERS] can we add SKIP LOCKED to UPDATE?

On 10 November 2015 at 01:38, Jeff Janes wrote: > this would be handy in conjunction with LIMIT > (which also doesn't exist for UPDATE right now). ... and, in turn, UPDATE ... ORDER BY ..., since LIMIT without ORDER BY is usually not a great choice. I'd quite like to see

Re: [HACKERS] eXtensible Transaction Manager API

On Mon, Nov 9, 2015 at 2:08 PM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > > On 09.11.2015 07:46, Amit Kapila wrote: > > I think so. Basically DLM should be responsible for maintaining > all the lock information which inturn means that any backend process > that needs to

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

Hello, I have some random comments on this patch addition to Amit's comments. - Type of the flag of vacuum activity. ACTIVITY_IS_VACUUM is the alone entry in the enum, and the variable to store it is named as *flag. If you don't have any plan to extend this information, the name of this variable

Re: [HACKERS] pg_receivexlog: spurious error message connecting to 9.3

On 10 November 2015 at 01:47, Marco Nenciarini wrote: > I've attached a little patch that removes the errors when connected to 9.3. Looks good to me. No point confusing users. The other callers of RunIdentifySystem are pg_basebackup and pg_receivelogical.

Re: [HACKERS] storage/buffer/README docs about buffer replacement are out of date

On Tue, Nov 10, 2015 at 3:34 AM, Andres Freund wrote: > > Hi, > > $subject contains: > > > The "clock hand" is a buffer index, nextVictimBuffer, that moves circularly > > through all the available buffers. nextVictimBuffer is protected by the > > buffer_strategy_lock. > > > >

Re: [HACKERS] Multixid hindsight design

On 10 November 2015 at 02:26, Robert Haas wrote: >> I'd like to see, say, python and the 'unittest' module added, and >> to see acceptance of tests using psycopg2 to stream and decode WAL >> from a slot. > > I actually kind of hate this sort of thing. For what it's worth,

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

It is a relevant topic of readfuncs support for custom-scan. Unlike CustomPath and CustomScanState, we don't allow custom-scan provider to define own and larger structure that embeds CustomScan at head of the structure, to support copyObject(). Thus, custom-scan provider needs to have own logic

Re: [HACKERS] Transactions involving multiple postgres foreign servers

> Any distributed transaction management requires 2PC in some or other form. > So, we should implement 2PC for FDW keeping in mind various forms of 2PC > used practically. Use that infrastructure to build XTM like capabilities > for restricted postgres_fdw uses. Previously, I have requested the

Re: [HACKERS] eXtensible Transaction Manager API

On 8 November 2015 at 23:35, Michael Paquier wrote: > > COMMIT PREPARED is a pretty thin layer; the work is all done in the > PREPARE. > > With a DTM, the main commit itself is done once only in the DTM, so all > the > > COMMIT PREPARED would do is release local node

Re: [HACKERS] Erroneous cost estimation for nested loop join

On Mon, Nov 9, 2015 at 11:08 AM, wrote: > > - cost parameter calibration: random_page_cost = 92.89 > This demands some explanation and raises question of value of seq_page_cost parameter -- I don't see anything about it your mail. -- Alex

[HACKERS] Minor comment improvement to create_foreignscan_plan

Hi, Here is a small patch to update an comment in create_foreignscan_plan; add fdw_recheck_quals to the list of expressions that need the replace_nestloop_params processing. I should have updated the comment when I proposed the patch for the fdw_recheck_quals. Best regards, Etsuro Fujita ***

Re: [HACKERS] Erroneous cost estimation for nested loop join

On 09/11/15 23:08, kawami...@tkl.iis.u-tokyo.ac.jp wrote: Hi guys, I’ve been using Postgres for research at an university, Great! [...] ・Postgres 9.4.1 [..] More knowledgeable people are sure to reply in more detail! However, they would probably appreciate it if you can run with 9.4.5

Re: [HACKERS] Erroneous cost estimation for nested loop join

On 9 November 2015 at 10:08, wrote: > > We guessed the cause of this error would be in the cost model of Postgres, > and investigated the source code of optimizer, and we found the cause of > this problem. It was in the index cost estimation process. On scanning

Re: [HACKERS] Getting sorted data from foreign server for merge join

On 2015/11/10 0:56, Robert Haas wrote: > On Sat, Nov 7, 2015 at 12:07 PM, Corey Huinker > wrote: >> Sorry to barge in late, but I was wondering if what we've learned with this >> patch can be applied to the case of asserting a sort order on a query >> returning from

Re: [HACKERS] Uh-oh: documentation PDF output no longer builds in HEAD

I wrote: > Curiously though, that gets us down to this: > 30615 strings out of 245828 > 397721 string characters out of 1810780 > which implies that indeed FlowObjectSetup *is* the cause of most of > the strings being entered. I'm not sure how that squares with the > observation that there are

Re: [HACKERS] Uh-oh: documentation PDF output no longer builds in HEAD

On 2015-11-09 19:46:37 -0500, Tom Lane wrote: > Well, after much digging, I've found what seems a workable answer. > It turns out that the original form of FlowObjectSetup is just > unbelievably awful [...]. > > This gets us down to ~135000 strings to build HEAD, and not incidentally, > the

Re: [HACKERS] Git cartoon

Fabrízio de Royes Mello wrote: > Em domingo, 8 de novembro de 2015, Bruce Momjian escreveu: >> This git cartoon was too funny not to share: >> >> http://xkcd.com/1597/ >> >> Maybe we need it on our git wiki page. ;-) > > I think we need our own cartoon with a funny

Re: [HACKERS] Adjust errorcode in background worker code

On 2015/11/07 3:55, Robert Haas wrote: > On Sun, Jun 28, 2015 at 10:43 PM, Amit Langote > wrote: >> On 2015-06-29 AM 11:36, Amit Langote wrote: >>> Hi, >>> >>> How about the attached that adjusts errorcode for the error related to >>> checking the flag bgw_flags in

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/09 13:40, Kouhei Kaigai wrote: Having said that, as I said previously, I don't see much value in adding the callback routine, to be honest. I know KaiGai-san considers that that would be useful for custom joins, but I don't think that that would be useful even for foreign joins,

Re: [HACKERS] Git cartoon

Em segunda-feira, 9 de novembro de 2015, Albe Laurenz < laurenz.a...@wien.gv.at> escreveu: > Fabrízio de Royes Mello wrote: > > Em domingo, 8 de novembro de 2015, Bruce Momjian > escreveu: > >> This git cartoon was too funny not to share: > >> > >>

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On 06.11.2015 21:37, Robert Haas wrote: On Wed, Aug 12, 2015 at 6:25 AM, Ashutosh Bapat wrote: The previous patch would not compile on the latest HEAD. Here's updated patch. Perhaps unsurprisingly, this doesn't apply any more. But we have bigger things to

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

On 11/06/2015 08:53 PM, Robert Haas wrote: On Fri, Nov 6, 2015 at 6:27 AM, Ildus Kurbangaliev wrote: There is a patch that splits SLRU LWLocks to separate tranches and moves them to SLRU Ctl. It does some work from the main patch from this thread, but can be

Re: [HACKERS] eXtensible Transaction Manager API

On 09.11.2015 07:46, Amit Kapila wrote: On Sat, Nov 7, 2015 at 10:23 PM, Konstantin Knizhnik > wrote: Lock manager is one of the tasks we are currently working on. There are still a lot of open questions: 1. Should

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

On Mon, 9 Nov 2015 15:14:02 +0800 Craig Ringer wrote: > > I'd rather not see convoluted and complex connstrings, per my prior > post. The JDBC extended URL style seems good enough. It is what my patch implements. > IMO the biggest problem is that client-side failover

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On 09.11.2015 09:59, Ashutosh Bapat wrote: Since the foreign server (referred to in the slides as secondary server) requires to call "create extension pg_dtm" and select dtm_join_transaction(xid);, I assume that the foreign server has to be a PostgreSQL server and one which has this

Re: [HACKERS] Some questions about the array.

On Sunday 08 November 2015 16:49:20 you wrote: > I'm not necessarily objecting to that, but it's not impossible that it > could break something for some existing user. We can decide not to > care about that, though. We had an idea. You can use ~ to convert the index to the array which always

Re: [HACKERS] Some questions about the array.

2015-11-09 12:36 GMT+01:00 YUriy Zhuravlev : > On Sunday 08 November 2015 16:49:20 you wrote: > > I'm not necessarily objecting to that, but it's not impossible that it > > could break something for some existing user. We can decide not to > > care about that, though.

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On 2015/11/09 13:40, Kouhei Kaigai wrote: > >> Having said that, as I said previously, I don't see much value in adding > >> the callback routine, to be honest. I know KaiGai-san considers that > >> that would be useful for custom joins, but I don't think that that would > >> be useful even for

Re: [HACKERS] Some questions about the array.

On Monday 09 November 2015 12:48:54 you wrote: > I am sorry - it is looking pretty obscure. Really need this feature? IMHO yes. Now for write: array[~2:~-2] you need like: array[array_lower(array, 1)+3: array_upper(array, 1)-2] Worse when long names. Besides the extra functions calls. Thanks.

Re: [HACKERS] Some questions about the array.

>From: pgsql-hackers-ow...@postgresql.org >[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Pavel Stehule >Sent: Montag, 9. November 2015 12:49 >To: YUriy Zhuravlev >Cc: PostgreSQL Hackers >Subject: Re: [HACKERS] Some questions about the array. > > > >2015-11-09 12:36 GMT+01:00 YUriy