Re: [HACKERS] Stopping logical replication protocol

2016-09-15 Thread Craig Ringer
On 9 September 2016 at 12:03, Craig Ringer wrote: > Setting "waiting on author" in CF per discussion of the need for tests. Have you had a chance to look at adding the tests we discussed? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Trai

Re: [HACKERS] kqueue

2016-09-15 Thread Thomas Munro
On Thu, Sep 15, 2016 at 11:04 AM, Thomas Munro wrote: > On Thu, Sep 15, 2016 at 10:48 AM, Keith Fiske wrote: >> Thomas Munro brought up in #postgresql on freenode needing someone to test a >> patch on a larger FreeBSD server. I've got a pretty decent machine (3.1Ghz >> Quad Core Xeon E3-1220V3, 1

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

2016-09-15 Thread Pavan Deolasee
On Fri, Sep 16, 2016 at 12:24 AM, Claudio Freire wrote: > On Thu, Sep 15, 2016 at 3:48 PM, Tomas Vondra > wrote: > > For example, we always allocate the TID array as large as we can fit into > > m_w_m, but maybe we don't need to wait with switching to the bitmap until > > filling the whole array

Re: [HACKERS] Parallel sec scan in plpgsql

2016-09-15 Thread Ashutosh Bapat
On Thu, Sep 15, 2016 at 9:15 PM, Alex Ignatov wrote: > Hello! > Does parallel secscan works in plpgsql? > Parallel seq scan is a query optimization that will work independent of the source of the query - i.e whether it comes directly from a client or a procedural language like plpgsql. So, I gues

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

2016-09-15 Thread Pavan Deolasee
On Fri, Sep 16, 2016 at 9:09 AM, Pavan Deolasee wrote: > > I also realised that we can compact the TID array in step (b) above > because we only need to store 17 bits for block numbers (we already know > which 1GB segment they belong to). Given that usable offsets are also just > 13 bits, TID arr

Re: [HACKERS] Hash Indexes

2016-09-15 Thread Amit Kapila
On Thu, Sep 15, 2016 at 7:25 PM, Robert Haas wrote: > On Thu, Sep 15, 2016 at 2:13 AM, Amit Kapila wrote: >> One other point, I would like to discuss is that currently, we have a >> concept for tracking active hash scans (hashscan.c) which I think is >> mainly to protect splits when the backend w

Re: [HACKERS] Tackling JsonPath support

2016-09-15 Thread Pavel Stehule
Hi 2016-09-15 18:05 GMT+02:00 Christian Convey : > On Mon, Sep 5, 2016 at 1:44 PM, Pavel Stehule > wrote: > ... > > > I wrote XMLTABLE function, and I am thinking about JSON_TABLE function. > But > > there is one blocker - missing JsonPath support in our JSON > implementation. > > > > So one ide

Re: [HACKERS] Hash Indexes

2016-09-15 Thread Amit Kapila
On Thu, Sep 15, 2016 at 7:53 PM, Andres Freund wrote: > Hi, > > On 2016-05-10 17:39:22 +0530, Amit Kapila wrote: >> For making hash indexes usable in production systems, we need to improve >> its concurrency and make them crash-safe by WAL logging them. > > One earlier question about this is wheth

Re: [HACKERS] Hash Indexes

2016-09-15 Thread Mark Kirkwood
On 16/09/16 18:35, Amit Kapila wrote: On Thu, Sep 15, 2016 at 7:53 PM, Andres Freund wrote: Hi, On 2016-05-10 17:39:22 +0530, Amit Kapila wrote: For making hash indexes usable in production systems, we need to improve its concurrency and make them crash-safe by WAL logging them. One earlier

<    1   2