Thread: Let's start talking features and "theme" for 9.4
All, So, we're closing in on a 9.4 beta. As such, I'd like to settle what we think are the "big features" for 9.4 which we're going to promote to the press, as well as seeing if we can come up with a "theme" which makes us more likely to get useful coverage. First let's start with a list. "Big features", that is the ones we want to lead with in press stuff: * JSONB et. al. * Logical Decoding/Changeset Extraction (need a marketing name for this feature, I like Logical Streaming Replication, but that's not complete yet) * Materialized Views * ALTER SYSTEM SET ... others? There's also a whole bunch of less prominent but interesting patches, including: * updatable security barrier views * new array manipulation and table functions * time-delayed standbys * dynamic background workers * MVCC system catalogs * Decrease lock level for some ALTER TABLE stuff ... others? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 22 April 2014 18:29, Josh Berkus <josh@agliodbs.com> wrote: > So, we're closing in on a 9.4 beta. As such, I'd like to settle what we > think are the "big features" for 9.4 which we're going to promote to the > press, as well as seeing if we can come up with a "theme" which makes us > more likely to get useful coverage. > > First let's start with a list. > > "Big features", that is the ones we want to lead with in press stuff: > > * JSONB et. al. > * Logical Decoding/Changeset Extraction (need a marketing name for this > feature, I like Logical Streaming Replication, but that's not complete yet) > * Materialized Views > * ALTER SYSTEM SET > ... others? > > There's also a whole bunch of less prominent but interesting patches, > including: > > * updatable security barrier views > * new array manipulation and table functions > * time-delayed standbys > * dynamic background workers > * MVCC system catalogs > * Decrease lock level for some ALTER TABLE stuff > ... others? They all sound good, apart from the MVCC system catalog changes. I'm also not comfortable saying Mat Views again, especially since we said it last time and they still don't work automatically in the optimizer, nor do they get auto updated. I think you should add * Write Scalability improvements - WAL Insert tuning * Aggregate performance improvements - tuning & negative transition functions * Huge pages * Update WAL reduction -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
> "Big features", that is the ones we want to lead with in press stuff: > > * JSONB et. al. we already had JSON (and operator/functions) as big features previously. > * Logical Decoding/Changeset Extraction (need a marketing name for > this feature, I like Logical Streaming Replication, but that's not > complete yet) Sure. > * Materialized Views This was already a big feature for 9.3 > * ALTER SYSTEM SET > ... others? > > There's also a whole bunch of less prominent but interesting patches, > including: > > * updatable security barrier views > * new array manipulation and table functions > * time-delayed standbys this can be a big feature. > * dynamic background workers > * MVCC system catalogs > * Decrease lock level for some ALTER TABLE stuff > ... others? * backup throttling (can be linked with time-delayed stdby) * GIN improvements * WITHIN GROUP * huge page usage ... -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Attachment
Hello
* support TB in work_mem2014-04-22 20:17 GMT+02:00 Simon Riggs <simon@2ndquadrant.com>:
On 22 April 2014 18:29, Josh Berkus <josh@agliodbs.com> wrote:
> So, we're closing in on a 9.4 beta. As such, I'd like to settle what we
> think are the "big features" for 9.4 which we're going to promote to the
> press, as well as seeing if we can come up with a "theme" which makes us
> more likely to get useful coverage.
>
> First let's start with a list.
>
> "Big features", that is the ones we want to lead with in press stuff:
>
> * JSONB et. al.
> * Logical Decoding/Changeset Extraction (need a marketing name for this
> feature, I like Logical Streaming Replication, but that's not complete yet)
> * Materialized Views
> * ALTER SYSTEM SET
> ... others?
>
> There's also a whole bunch of less prominent but interesting patches,
> including:
>
> * updatable security barrier views
> * new array manipulation and table functions
> * time-delayed standbys
> * dynamic background workers
> * MVCC system catalogs
> * Decrease lock level for some ALTER TABLE stuff
> ... others?
They all sound good, apart from the MVCC system catalog changes. I'm
also not comfortable saying Mat Views again, especially since we said
it last time and they still don't work automatically in the optimizer,
nor do they get auto updated.
I think you should add
* Write Scalability improvements - WAL Insert tuning
* Aggregate performance improvements - tuning & negative transition functions
* Huge pages
* Update WAL reduction
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy
On 04/22/2014 11:17 AM, Simon Riggs wrote: > They all sound good, apart from the MVCC system catalog changes. I'm > also not comfortable saying Mat Views again, especially since we said > it last time and they still don't work automatically in the optimizer, > nor do they get auto updated. Actually, we deliberately downplayed the matviews in the last release because of discussion on this list. Now we have refresh matview concurrently, which makes them substantially more useful, at least to me. At some point we need to make them a "feature", and I think this is that point. > I think you should add > > * Write Scalability improvements - WAL Insert tuning > * Aggregate performance improvements - tuning & negative transition functions > * Huge pages > * Update WAL reduction What did we do with huge pages? Do we have any stats for the performance improvements? On 04/22/2014 11:35 AM, Cédric Villemain wrote:>> "Big features", that is the ones we want to lead with in press stuff: >> >> * JSONB et. al. > > we already had JSON (and operator/functions) as big features previously. You seem to be completely unaware of the new JSON storage format and features. That's OK; it's why we do this ... >> * Materialized Views > > This was already a big feature for 9.3 Actually, it wasn't; see above. > * backup throttling (can be linked with time-delayed stdby) Oh, cool. Can you explain this? > * GIN improvements > * WITHIN GROUP > * huge page usage > ... Oh, right WITHIN GROUP. How could I forget. On 04/22/2014 11:38 AM, Pavel Stehule wrote: > * support TB in work_mem I'm not sure about this as a feature. You can declare it, but we can't actually *use* it effectively, AFAIK. > * faster numeric sum and avg > * faster window function - moving average, percentiles Again, got any figures? People love to know stats when we say "faster performance" ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Wed, Apr 23, 2014 at 10:38 AM, Josh Berkus <josh@agliodbs.com> wrote:
-- On 04/22/2014 11:35 AM, Cédric Villemain wrote:>> "Big features", thatis the ones we want to lead with in press stuff:
>>
>> * JSONB et. al.
>> we already had JSON (and operator/functions) as big features previously.You seem to be completely unaware of the new JSON storage format and
features. That's OK; it's why we do this ...
In this case, insist on the new gin indexing capabilities, that's the most important part of the jsonb set IMO.
Michael
> On 04/22/2014 11:35 AM, Cédric Villemain wrote:>> "Big features", that > is the ones we want to lead with in press stuff: > >> * JSONB et. al. > > > > we already had JSON (and operator/functions) as big features > > previously. > You seem to be completely unaware of the new JSON storage format and > features. That's OK; it's why we do this ... I'm aware. We cannot replace JSON thus we found another name for the same thing better implemented. It's true that this can be highlighted for the new expected performances and indexing support. > >> * Materialized Views > > > > This was already a big feature for 9.3 > > Actually, it wasn't; see above. Correct, I confused advocacy and release note (mat view is the first top item in the 9.3 release notes) > > * backup throttling (can be linked with time-delayed stdby) > > Oh, cool. Can you explain this? The purpose of this feature is to limit impact of pg_backup on running server. -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Attachment
Hi, Am Dienstag, den 22.04.2014, 18:38 -0700 schrieb Josh Berkus: > On 04/22/2014 11:17 AM, Simon Riggs wrote: > > I think you should add > > > > * Write Scalability improvements - WAL Insert tuning [...] > Do we have any stats for the performance improvements? For scalability improvements, there is a rather impressive graph in Heikki's original post, I believe this is what Simon mentioned: http://www.postgresql.org/message-id/52243ABB.5070903@vmware.com Michael -- Michael Banck Projektleiter / Berater Tel.: +49 (2161) 4643-171 Fax: +49 (2161) 4643-100 Email: michael.banck@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
On Apr 22, 2014, at 7:29 PM, Josh Berkus <josh@agliodbs.com> wrote: > "Big features", that is the ones we want to lead with in press stuff: > > * JSONB et. al. I think to echo some of the earlier statements, the important thing is how we label this feature. "Enhanced JSON accessthat rivals other NoSQL system speeds" or the like would generate a lot of buzz. And we can definitely play-up theGIN indexing improvements around this and show what other data types / systems reap the benefits of those. > * Logical Decoding/Changeset Extraction (need a marketing name for this > feature, I like Logical Streaming Replication, but that's not complete yet) Then perhaps we hold off highlighting this feature, similar to what we did with mat views for 9.3? Ultimately, once "logicalstreaming replication" is complete, the tag line is "replicate PostgreSQL information into *any* system" Jonathan
I agree with what Jonathan said here. -- Darren Duncan On 2014-04-23, 2:13 AM, Jonathan S. Katz wrote: > On Apr 22, 2014, at 7:29 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> "Big features", that is the ones we want to lead with in press stuff: >> >> * JSONB et. al. > > I think to echo some of the earlier statements, the important thing is how we label this feature. "Enhanced JSON accessthat rivals other NoSQL system speeds" or the like would generate a lot of buzz. And we can definitely play-up theGIN indexing improvements around this and show what other data types / systems reap the benefits of those. >> * Logical Decoding/Changeset Extraction (need a marketing name for this >> feature, I like Logical Streaming Replication, but that's not complete yet) > > Then perhaps we hold off highlighting this feature, similar to what we did with mat views for 9.3? Ultimately, once "logicalstreaming replication" is complete, the tag line is "replicate PostgreSQL information into *any* system" > > Jonathan
> > I agree with what Jonathan said here. -- Darren Duncan > > On 2014-04-23, 2:13 AM, Jonathan S. Katz wrote: >> On Apr 22, 2014, at 7:29 PM, Josh Berkus <josh@agliodbs.com> wrote: >> >>> "Big features", that is the ones we want to lead with in press stuff: >>> >>> * JSONB et. al. >> >> I think to echo some of the earlier statements, the important thing is >> how we label this feature. "Enhanced JSON access that rivals other >> NoSQL system speeds" or the like would generate a lot of buzz. And we >> can definitely play-up the GIN indexing improvements around this and >> show what other data types / systems reap the benefits of those. "JSONB more fast speed" >>> * Logical Decoding/Changeset Extraction (need a marketing name for this >>> feature, I like Logical Streaming Replication, but that's not complete >>> yet) >> >> Then perhaps we hold off highlighting this feature, similar to what we >> did with mat views for 9.3? Ultimately, once "logical streaming >> replication" is complete, the tag line is "replicate PostgreSQL >> information into *any* system" You can provide this functionality to confound, can you give more details on its use? >> Jonathan > Saludos, Gilberto Castillo La Habana, Cuba --- This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at host imx3.etecsa.cu Visit our web-site: <http://www.kaspersky.com>, <http://www.viruslist.com>
On 22 April 2014 18:29, Josh Berkus <josh@agliodbs.com> wrote: > * Logical Decoding/Changeset Extraction (need a marketing name for this > feature, I like Logical Streaming Replication, but that's not complete yet) Oracle calls this Change Data Capture Logical Decoding begs the questions "of what?". Changeset Extraction is a better name. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
> > On 22 April 2014 18:29, Josh Berkus <josh@agliodbs.com> wrote: > >> * Logical Decoding/Changeset Extraction (need a marketing name for this >> feature, I like Logical Streaming Replication, but that's not complete >> yet) > > Oracle calls this Change Data Capture > > Logical Decoding begs the questions "of what?". Changeset Extraction > is a better name. Oh Partial Streaming Replication Saludos, Gilberto Castillo La Habana, Cuba --- This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at host imx3.etecsa.cu Visit our web-site: <http://www.kaspersky.com>, <http://www.viruslist.com>
Simon Riggs wrote: > Logical Decoding begs the questions "of what?". Changeset Extraction > is a better name. Changeset Extraction sounds too geeky to me. Let me try some simplification of it. Why "set"? We capture each change; whether together they form a set doesn't matter much. Also, since the changes we're talking about occur in the stored data, I propose we use "Data Change" rather than "Changeset". Also, why "Extract"? We're not extracting these changes after the fact -- rather we capture them as they transit through the WAL system. So, I would propose "Data Change Capture". -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 23 April 2014 20:55, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Simon Riggs wrote: > >> Logical Decoding begs the questions "of what?". Changeset Extraction >> is a better name. > > Changeset Extraction sounds too geeky to me. Let me try some > simplification of it. Why "set"? We capture each change; whether > together they form a set doesn't matter much. Also, since the changes > we're talking about occur in the stored data, I propose we use "Data > Change" rather than "Changeset". Also, why "Extract"? We're not > extracting these changes after the fact -- rather we capture them as > they transit through the WAL system. > > So, I would propose "Data Change Capture". How about "Change Streaming" ? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 04/23/2014 02:13 AM, Jonathan S. Katz wrote: > On Apr 22, 2014, at 7:29 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> "Big features", that is the ones we want to lead with in press >> stuff: >> >> * JSONB et. al. > > I think to echo some of the earlier statements, the important thing > is how we label this feature. "Enhanced JSON access that rivals > other NoSQL system speeds" or the like would generate a lot of buzz. > And we can definitely play-up the GIN indexing improvements around > this and show what other data types / systems reap the benefits of > those. Yes, and also the JSON manipulation functions which make it possible to do extract/merge/aggregate of JSON. That's why I said "et. al.", I was referring to the whole package of JSON "stuff". It might be worth giving a shout-out to Mongres and pgREST in the presskit. >> * Logical Decoding/Changeset Extraction (need a marketing name for >> this feature, I like Logical Streaming Replication, but that's not >> complete yet) > > Then perhaps we hold off highlighting this feature, similar to what > we did with mat views for 9.3? Ultimately, once "logical streaming > replication" is complete, the tag line is "replicate PostgreSQL > information into *any* system" Well, the question is, can we do anything practically useful with CE/LD as it is in 9.4 right now? If no, the we hold off until we have the complete set of stuff. If so, we announce it now, and announce the additional features in 9.4/10.0. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 2014-04-23 15:30:58 -0700, Josh Berkus wrote: > > Then perhaps we hold off highlighting this feature, similar to what > > we did with mat views for 9.3? Ultimately, once "logical streaming > > replication" is complete, the tag line is "replicate PostgreSQL > > information into *any* system" > > Well, the question is, can we do anything practically useful with CE/LD > as it is in 9.4 right now? If no, the we hold off until we have the > complete set of stuff. If so, we announce it now, and announce the > additional features in 9.4/10.0. * build/improve replication solutions * auditing * cache invalidation * ... So, yes. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 04/23/2014 01:06 PM, Simon Riggs wrote: > On 23 April 2014 20:55, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> Simon Riggs wrote: >> >>> Logical Decoding begs the questions "of what?". Changeset Extraction >>> is a better name. >> >> Changeset Extraction sounds too geeky to me. Let me try some >> simplification of it. Why "set"? We capture each change; whether >> together they form a set doesn't matter much. Also, since the changes >> we're talking about occur in the stored data, I propose we use "Data >> Change" rather than "Changeset". Also, why "Extract"? We're not >> extracting these changes after the fact -- rather we capture them as >> they transit through the WAL system. >> >> So, I would propose "Data Change Capture". > > How about "Change Streaming" ? I like that one. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 23 April 2014 23:30, Josh Berkus <josh@agliodbs.com> wrote: > Well, the question is, can we do anything practically useful with CE/LD > as it is in 9.4 right now? Yes, you can. An accurate, complete and usable mechanism for extracting changesets that is likely to be used in many interesting ways for integrating PostgreSQL into larger solutions and enterprises. > If no, the we hold off until we have the > complete set of stuff. If so, we announce it now, and announce the > additional features in 9.4/10.0. Define "complete set of stuff". Hopefully the more obvious logical replication facilities will be in core by 9.5, but there are many possible features associated with these technologies and many of those will never be in core because they relate to integration with other software, much of it with incompatible licencing. Having an API that enables out-of-core solutions is more powerful and useful to PostgreSQL users than having it in-core. It would be a mistake to regard what we have as incomplete. We can expect rapid development of solutions around this. This is different to Mat Views because the initial implementation of that lacked an important aspect of usability (in that it exclusively locked the mat view while it was refreshed, making it unusable in production for highly available systems). No doubt we will discover some useful additional features of CE/LD, but the main parts are very usable and performant. So my description for advocacy of CE/LD is * Changeset Extraction API - high performance mechanism for reading a stream of changes from the database, enabling integration with other software servers. This is the core technology that will be built on in later releases to add Online Upgrades, Logical Replication and eventually Sharded and Massively Parallel systems. Downstream developers are invited to use the new API to enable deep integration of PostgreSQL into complex/enterprise data processing environments. This important new technology solidifies PostgreSQL role as database of choice for front line production systems that can feed data efficiently throughout the enterprise. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Am Donnerstag, den 24.04.2014, 07:32 +0100 schrieb Simon Riggs: > So my description for advocacy of CE/LD is > > * Changeset Extraction API - high performance mechanism for reading a > stream of changes from the database, enabling integration with other > software servers. This is the core technology that will be built on in > later releases to add Online Upgrades, Logical Replication and > eventually Sharded and Massively Parallel systems. Downstream > developers are invited to use the new API to enable deep integration > of PostgreSQL into complex/enterprise data processing environments. > This important new technology solidifies PostgreSQL role as database > of choice for front line production systems that can feed data > efficiently throughout the enterprise. Sounds great. Maybe somebody from the Slony project wants to contribute a quote that they are excited about this feature and are planning to use it? (if that is indeed the case, of course). Michael -- Michael Banck Projektleiter / Berater Tel.: +49 (2161) 4643-171 Fax: +49 (2161) 4643-100 Email: michael.banck@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
On 04/23/2014 11:32 PM, Simon Riggs wrote: >> If no, the we hold off until we have the >> complete set of stuff. If so, we announce it now, and announce the >> additional features in 9.4/10.0. > > Define "complete set of stuff". Not relevant, because both you and Andres have pointed out that it's useful *now*. > So my description for advocacy of CE/LD is > > * Changeset Extraction API - high performance mechanism for reading a > stream of changes from the database, enabling integration with other > software servers. This is the core technology that will be built on in > later releases to add Online Upgrades, Logical Replication and > eventually Sharded and Massively Parallel systems. Downstream > developers are invited to use the new API to enable deep integration > of PostgreSQL into complex/enterprise data processing environments. > This important new technology solidifies PostgreSQL role as database > of choice for front line production systems that can feed data > efficiently throughout the enterprise. Thanks! However ... I liked your name "Change Streaming" better. So, "Change Streaming API"? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Apr 24, 2014, at 7:14 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 04/23/2014 11:32 PM, Simon Riggs wrote:
>>> If no, the we hold off until we have the
>>> complete set of stuff. If so, we announce it now, and announce the
>>> additional features in 9.4/10.0.
>>
>> Define "complete set of stuff".
>
> Not relevant, because both you and Andres have pointed out that it's
> useful *now*.
+1
>> So my description for advocacy of CE/LD is
>>
>> * Changeset Extraction API - high performance mechanism for reading a
>> stream of changes from the database, enabling integration with other
>> software servers. This is the core technology that will be built on in
>> later releases to add Online Upgrades, Logical Replication and
>> eventually Sharded and Massively Parallel systems. Downstream
>> developers are invited to use the new API to enable deep integration
>> of PostgreSQL into complex/enterprise data processing environments.
>> This important new technology solidifies PostgreSQL role as database
>> of choice for front line production systems that can feed data
>> efficiently throughout the enterprise.
>
> Thanks!
>
> However ... I liked your name "Change Streaming" better. So, "Change
> Streaming API"?
When I look at "Change Streaming API" from a 50,000ft level, I'm not entirely sure what it means ("what changes are
streaming?"). Perhaps:
* Data Change Streaming API
* Changeset Streaming API (playing off of "Changeset Extraction API")
OTOH, if we leave it as "Change Streaming API," when talking about it, we would say something like the "PostgreSQL
ChangeStreaming API" which makes it easier to understand.
Jonathan
>> However ... I liked your name "Change Streaming" better. So, "Change
>> Streaming API"?
>
> When I look at "Change Streaming API" from a 50,000ft level, I'm not entirely sure what it means ("what changes are
streaming?"). Perhaps:
>
> * Data Change Streaming API
> * Changeset Streaming API (playing off of "Changeset Extraction API")
See prior comments about the word "changeset" on this thread.
+1 to Data Change Streaming API (DCS-API, sounds like an RFCC ...)
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On 23-04-14 22:48, Gilberto Castillo wrote:
This feature sounds similar to what incremental backups do, so how about Incremental Streaming Replication?On 22 April 2014 18:29, Josh Berkus <josh@agliodbs.com> wrote:* Logical Decoding/Changeset Extraction (need a marketing name for this feature, I like Logical Streaming Replication, but that's not complete yet)Oracle calls this Change Data Capture Logical Decoding begs the questions "of what?". Changeset Extraction is a better name.Oh Partial Streaming Replication Saludos, Gilberto Castillo La Habana, Cuba--- This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at host imx3.etecsa.cu Visit our web-site: <http://www.kaspersky.com>, <http://www.viruslist.com>
All, Just realized that our list didn't include: Dynamic background workers ... the question is whether this is a top feature or an "other" feature. Can someone do something cool with this right now? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
2014-05-01 21:31 GMT+02:00 Josh Berkus <josh@agliodbs.com>:
All,
Just realized that our list didn't include:
Dynamic background workers
... the question is whether this is a top feature or an "other" feature.
Can someone do something cool with this right now?
It is highly important - for PostgreSQL hackers only (and it continues in better extensibility ever year, so paradoxically, it is not something new) - I don't expect so usual user can use it in next two years.
but I am looking for, so in early next versions some interesting bgworkers will be in core - scheduler, idle connection killer, multi CPU sorter, ...
So I am thinking, it should be marked as "other" feature this year.
regards
Pavel
Pavel
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy
On Fri, May 2, 2014 at 4:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > but I am looking for, so in early next versions some interesting bgworkers > will be in core - scheduler, idle connection killer, multi CPU sorter, ... -1 for that. Those bgworkers things satisfy very specific needs (I implemented one of them in the list). I'd rather see a wiki page listing them properly and let each implementer maintain their code. > So I am thinking, it should be marked as "other" feature this year. +1 for that. Dynamic background workers is a hacker feature. -- Michael
On Fri, 2014-05-02 at 08:36 +0900, Michael Paquier wrote: > On Fri, May 2, 2014 at 4:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > but I am looking for, so in early next versions some interesting bgworkers > > will be in core - scheduler, idle connection killer, multi CPU sorter, ... > -1 for that. Those bgworkers things satisfy very specific needs (I > implemented one of them in the list). I'd rather see a wiki page > listing them properly and let each implementer maintain their code. > Completely agree with Michael. I see them just like FDWs. We don't add some FDW in the core. Some are contrib modules, some are available elsewhere. BgWorkers should be handled the same way. > > So I am thinking, it should be marked as "other" feature this year. > +1 for that. Dynamic background workers is a hacker feature. +1 -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
2014-05-02 10:56 GMT+02:00 Guillaume Lelarge <guillaume@lelarge.info>:
On Fri, 2014-05-02 at 08:36 +0900, Michael Paquier wrote:
> On Fri, May 2, 2014 at 4:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> > but I am looking for, so in early next versions some interesting bgworkers
> > will be in core - scheduler, idle connection killer, multi CPU sorter, ...
> -1 for that. Those bgworkers things satisfy very specific needs (I
> implemented one of them in the list). I'd rather see a wiki page
> listing them properly and let each implementer maintain their code.
>
Completely agree with Michael. I see them just like FDWs. We don't add
some FDW in the core. Some are contrib modules, some are available
elsewhere. BgWorkers should be handled the same way.
When I spoke "core" - I though a "contrib" resp. upstream
Pavel
> > So I am thinking, it should be marked as "other" feature this year.
> +1 for that. Dynamic background workers is a hacker feature.
+1
--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com
On Fri, 2014-05-02 at 11:10 +0200, Pavel Stehule wrote: > 2014-05-02 10:56 GMT+02:00 Guillaume Lelarge <guillaume@lelarge.info>: > > > On Fri, 2014-05-02 at 08:36 +0900, Michael Paquier wrote: > > > On Fri, May 2, 2014 at 4:39 AM, Pavel Stehule <pavel.stehule@gmail.com> > > wrote: > > > > but I am looking for, so in early next versions some interesting > > bgworkers > > > > will be in core - scheduler, idle connection killer, multi CPU sorter, > > ... > > > -1 for that. Those bgworkers things satisfy very specific needs (I > > > implemented one of them in the list). I'd rather see a wiki page > > > listing them properly and let each implementer maintain their code. > > > > > > > Completely agree with Michael. I see them just like FDWs. We don't add > > some FDW in the core. Some are contrib modules, some are available > > elsewhere. BgWorkers should be handled the same way. > > > > When I spoke "core" - I though a "contrib" resp. upstream > Oh OK. Then I'm fine with adding some as contrib modules :) -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On 04/22/2014 09:35 PM, Cédric Villemain wrote: > * GIN improvements This! GIN indexes are now 50% smaller and searches are much faster. They are now competitive with bitmap indexes on other DBMS's. (By competitive, I don't mean better :-). But good enough to be used for similar use cases) - Heikki
On 6 May 2014 09:01, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > GIN indexes are now 50% smaller and searches are much faster. They are now > competitive with bitmap indexes on other DBMS's. > > (By competitive, I don't mean better :-). But good enough to be used for > similar use cases) I think you've done great work there, as well as others. "competitive with bitmap indexes" needs a full technical analysis, so definitely shouldn't form any part of marketing until we can see its definitely true, for all important use cases. If it is true or close enough, I'm more than happy to avoid further work on bitmap indexes and ecstatic that we've got this important functionality into PG in this release rather than next. If it isn't sufficiently true, the assertion will block the development of bitmaps by undermining the concept, which won't help us. An assertion alone doesn't help us decide... -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services