Re: Having query cache in core

Tom Lane wrote: > Tatsuo Ishii writes: > > Does anybody think having in-memory query result cache in core is a > > good idea? > > No. I agree. Having been bitten by the feature on MySQL, I think it's not a good thing. Essentially, it's a band-aid for badly written applications, but it will onl

Re: citext function overloads for text parameters

> > > Do you think it would be appropriate to simply add an strpos(citext, > text) > > overload to the extension to make sure this behaves more as expected? If > so > > I can try to submit a patch at some point. > > To me, if there's both a citext and a text parameter, then it's simply > unclear wh

Re: Should we add GUCs to allow partition pruning to be disabled?

Many thanks for reviewing this. On 2 May 2018 at 20:07, Amit Langote wrote: > + > +Partition Pruning is also more powerful than constraint exclusion as > +partition pruning is not something that is performed only during the > +planning of a given query. > > Maybe, don't repeat "par

Re: Should we add GUCs to allow partition pruning to be disabled?

Thanks for looking at this. I've taken most of your suggestions, some I had changed around as a result of Amit's review. On 7 May 2018 at 15:34, Justin Pryzby wrote: > + During actual execution of the query plan. Partition pruning may also > Remove "actual" ? I left this out one. I imagin

Re: Draft release notes are up

> On May 4, 2018, at 7:18 PM, Tom Lane wrote: > > Michael Paquier writes: >> On Fri, May 04, 2018 at 07:00:18PM -0400, Tom Lane wrote: >> + >> + >> + >> + Support building with Microsoft Visual Studio 2015 (Michael Paquier) >> + > >> This will only be part of release-9.5.sgm

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, Apr 26, 2018 at 07:29:37PM +1200, David Rowley wrote: > On 25 April 2018 at 09:59, Alvaro Herrera wrote: > > Amit Langote wrote: > >> Although the config.sgml coverage of the new capabilities seems pretty > >> good, some may find their being mentioned in 5.10 Table Partitioning > >> helpfu

Re: Having query cache in core

Tatsuo Ishii writes: > Does anybody think having in-memory query result cache in core is a > good idea? No. regards, tom lane

Re: Why did commit 6271fceb8 enable debug logging for all TAP tests?

Michael Paquier writes: > On Sun, May 06, 2018 at 09:49:46PM -0400, Tom Lane wrote: >> Now, that was neither mentioned in the commit message nor justified >> by any added test cases or scaffolding, so I'm assuming it was simply a >> mistake and should be reverted. Please confirm. > That was arou

Having query cache in core

Does anybody think having in-memory query result cache in core is a good idea? From the experience of implementing the feature in Pgpool-II, I would think this is not terribly hard job. But first of all I'm wondering if there's a demand for the feature. Best regards, -- Tatsuo Ishii SRA OSS, Inc.

Re: Why did commit 6271fceb8 enable debug logging for all TAP tests?

On Sun, May 06, 2018 at 09:49:46PM -0400, Tom Lane wrote: > Now, that was neither mentioned in the commit message nor justified > by any added test cases or scaffolding, so I'm assuming it was simply a > mistake and should be reverted. Please confirm. That was around to check that the debug messa

Why did commit 6271fceb8 enable debug logging for all TAP tests?

I've been trying to trace down a slowdown in HEAD's regression tests compared to the v10 branch, and one thing I discovered is that there was a noticeable across-the-board slowdown in the TAP tests as a result of commit 6271fceb8; as much as 10% for the "scripts" tests, though less in other places.

Re: [HACKERS] path toward faster partition pruning

On Fri, May 04, 2018 at 12:32:23PM +0300, Marina Polyakova wrote: > I got a similar server crash as in [1] on the master branch since the commit > 9fdb675fc5d2de825414e05939727de8b120ae81 when the assertion fails because > the second argument ScalarArrayOpExpr is not a Const or an ArrayExpr, but is

Re: perlcritic and perltidy

Michael, * Michael Paquier (mich...@paquier.xyz) wrote: > On Sun, May 06, 2018 at 01:46:28PM -0400, Stephen Frost wrote: > > I definitely prefer to have the braces on their own line- makes working > > with the files a lot easier when you've got a lot of hashes > > (particularly thinking about the

Re: perlcritic and perltidy

On Sun, May 06, 2018 at 01:46:28PM -0400, Stephen Frost wrote: > I definitely prefer to have the braces on their own line- makes working > with the files a lot easier when you've got a lot of hashes > (particularly thinking about the hashes for the pg_dump regression > tests..). Having them on ind

Refreshing findoidjoins for v11

Hi all, Wouldn't it be time to update the list of catalog joins generated by findoidjoins? Running it myself, I have spotted two new links: +Join pg_catalog.pg_constraint.conparentid => pg_catalog.pg_constraint.oid +Join pg_catalog.pg_partitioned_table.partdefid => pg_catalog.pg_class.oid 86f575

Extra newlines added even if PQerrorMessage

Hi all, 2f52518 has removed a couple of extra newlines not needed as PQerrorMessage is used, but some places have been missed: - testlo64.c - testlo.c - findoidjoins.c Those are not really critical, still I think that it would be good practice to be consistent. pgbench uses at one place CommandFa

Re: GSoC 2018: thrift encoding format

Thanks guys for your ideas! I feel like it is easier to follow pg_protobuf 's method to design and implement pg_thrift for a postgres beginner like me. I can refer pg_protobuf's way of using functions, writing tests, etc. I will reconsider what's the returned format for list, sets, and struct, etc.

Re: WIP: a way forward on bootstrap data

> On May 6, 2018, at 12:08 PM, John Naylor wrote: > > On 5/7/18, Mark Dilger wrote: >> Hackers, >> >> Have you already considered and rejected the idea of having >> genbki.pl/Catalog.pm define constants that can be used in >> the catalog .dat files? I'm mostly curious if people think >> the r

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On 3 April 2018 at 15:34, Ashutosh Bapat > wrote: > On Fri, Mar 30, 2018 at 7:36 PM, Ashutosh Bapat > wrote: >> >> I am working on commenting portions of the code to make it more clear >> and readable. Will update the patches with the comments soon, mostly >> this Monday. >> > > Here's set of

Re: WIP: a way forward on bootstrap data

On 5/7/18, Mark Dilger wrote: > Hackers, > > Have you already considered and rejected the idea of having > genbki.pl/Catalog.pm define constants that can be used in > the catalog .dat files? I'm mostly curious if people think > the resulting .dat files are better or worse using constants > of thi

Re: WIP: a way forward on bootstrap data

Mark Dilger writes: > Have you already considered and rejected the idea of having > genbki.pl/Catalog.pm define constants that can be used in > the catalog .dat files? I'm mostly curious if people think > the resulting .dat files are better or worse using constants > of this sort. For example:

Re: WIP: a way forward on bootstrap data

Hackers, Have you already considered and rejected the idea of having genbki.pl/Catalog.pm define constants that can be used in the catalog .dat files? I'm mostly curious if people think the resulting .dat files are better or worse using constants of this sort. For example: diff --git a/src/bac

Re: [HACKERS] Clock with Adaptive Replacement

06.05.2018 20:28, Andrey Borodin пишет: > >> 6 мая 2018 г., в 20:38, Yura Sokolov написал(а): >> >> I've been playing with logarithmic scale in postgresql roughly year ago. >> I didn't found any benefits compared to current code. In fact, it looked >> to perform worse than current code. >> That i

Re: perlcritic and perltidy

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan writes: > > On 05/06/2018 11:53 AM, Tom Lane wrote: > >> What sort of changes do we get if we remove those two flags as you prefer? > >> It'd help to see some examples. > > > Essentially it adds some vertical whitespace to struct

Re: [HACKERS] Clock with Adaptive Replacement

> 6 мая 2018 г., в 20:38, Yura Sokolov написал(а): > > I've been playing with logarithmic scale in postgresql roughly year ago. > I didn't found any benefits compared to current code. In fact, it looked > to perform worse than current code. > That is why I didn't wrote about that experiment to p

Re: perlcritic and perltidy

Andrew Dunstan writes: > On 05/06/2018 11:53 AM, Tom Lane wrote: >> What sort of changes do we get if we remove those two flags as you prefer? >> It'd help to see some examples. > Essentially it adds some vertical whitespace to structures so that the > enclosing braces etc appear on their own lin

Re: perlcritic and perltidy

Andrew Dunstan writes: > The attached patch allows a clean run from the following script adapted > from pgperltidy: I'm hardly a perl expert, but those changes look reasonable. > w.r.t. perltidy, I note that our policy has these two lines: > --vertical-tightness=2 > --vertical-tightness-

Re: [HACKERS] Clock with Adaptive Replacement

06.05.2018 11:20, Andrey Borodin пишет: > > >> 5 мая 2018 г., в 13:25, Yura Sokolov написал(а): >> >> 05.05.2018 09:16, Andrey Borodin пишет: >>> Hi! >>> 4 мая 2018 г., в 16:05, Юрий Соколов написал(а): I didn't suggest log scale of usages, but rather "replacement-perio

Re: citext function overloads for text parameters

Shay Rojansky writes: > Do you think it would be appropriate to simply add an strpos(citext, text) > overload to the extension to make sure this behaves more as expected? If so > I can try to submit a patch at some point. To me, if there's both a citext and a text parameter, then it's simply uncl

perlcritic and perltidy

The attached patch allows a clean run from the following script adapted from pgperltidy: {     find . -type f -a \( -name '*.pl' -o -name '*.pm' \) -print     find . -type f -perm -100 -exec file {} \; -print \            | egrep -i ':.*perl[0-9]*\>' \            | cut -d: -f1

Re: citext function overloads for text parameters

2018-05-06 14:55 GMT+02:00 Shay Rojansky : > Thanks for your answer Pavel. > > This is expected - it is side effect of PostgreSQL implementation of >> function overloading and type conversions >> >> after installation citext, you will have more instances of function strpos >> >> strpos(citext, cit

Re: citext function overloads for text parameters

Thanks for your answer Pavel. This is expected - it is side effect of PostgreSQL implementation of > function overloading and type conversions > > after installation citext, you will have more instances of function strpos > > strpos(citext, citext) > strpos(text, text) > Do you think it would be

Re: Global snapshots

> On 4 May 2018, at 22:09, Robert Haas wrote: > > So, is the idea that we'll definitely find out about any remote > transactions within 30 seconds, and then after we know about remote > transactions, we'll hold back OldestXmin some other way? Yes, kind of. There is a procArray->global_snapshot

Re: [HACKERS] Clock with Adaptive Replacement

5 мая 2018 г., в 13:25, Yura Sokolov написал(а):05.05.2018 09:16, Andrey Borodin пишет:Hi!4 мая 2018 г., в 16:05, Юрий Соколов написал(а):I didn't suggest log scale of usages, but rather"replacement-period based" increment: usage count could beincrem