Hi all,
While hacking on an extension, I have finished by doing things similar
to guc_malloc & friends for the allocation of a GUC parameter for malloc
portability. While that's not really a big deal to copy/paste this
code, I am wondering if it would make sense to expose them for extension
devel
25.04.2018 11:45, insaf.k wrote:
I've done some research regarding compiling in Windows. I am not sure
in what way I should compile the extension. AFAIK, Visual Studio is
not POSIX compliant and so I'll have to rewrite all those POSIX calls
using Windows API. So it's better to compile the exten
On 2018/03/01 17:16, Amit Langote wrote:
> Added this to CF (actually moved to the September one after first having
> added it to the CF that is just getting started).
>
> It seems to me that we don't need to go with my originally proposed
> approach to teach predtest.c to strip RelabelType nodes.
Hello Marina,
FYI the v8 patch does not apply anymore, mostly because of a recent perl
reindentation.
I think that I'll have time for a round of review in the first half of
July. Providing a rebased patch before then would be nice.
--
Fabien.
07.05.2018 20:07, Tom Lane wrote:
Robert Haas writes:
After thinking about this some more, I think the question here is
definitional. A first attempt at defining 'make installcheck' is to
say that it runs the tests from the build tree against the running
server. Certainly, we intend to use th
On Tue, May 8, 2018 at 5:23 AM, Robert Haas wrote:
> On Sat, Apr 7, 2018 at 10:21 AM, Adrien Nayrat
> wrote:
>> I notice Parallel append is not listed on Parallel Plans documentation :
>> https://www.postgresql.org/docs/devel/static/parallel-plans.html
>
> I agree it might be nice to mention this
On Mon, May 7, 2018 at 11:07 PM, Robert Haas wrote:
> In the wake of commit e89a71fb449af2ef74f47be1175f99956cf21524,
> parallel.sgml is no longer correct about the effect of InitPlans:
>
>
> The following operations are always parallel restricted.
>
>
> ...
>
>
> Access t
On Sun, May 06, 2018 at 09:14:06PM -0400, Stephen Frost wrote:
> While I appreciate the support, I'm not sure that you're actually
> agreeing with me.. I was arguing that braces should be on their own
> line and therefore there would be a new line for the brace.
> Specifically, when moving lines b
On Mon, May 07, 2018 at 02:32:48PM -0400, Tom Lane wrote:
> Pushed, thanks for doing the legwork.
Thanks.
--
Michael
signature.asc
Description: PGP signature
2018-05-07 19:52 GMT+02:00 Robert Haas :
> On Sun, May 6, 2018 at 10:32 PM, Tatsuo Ishii wrote:
> > 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
Michael Paquier writes:
> Wouldn't it be time to update the list of catalog joins generated by
> findoidjoins?
Pushed, thanks for doing the legwork.
regards, tom lane
On Fri, Mar 30, 2018 at 11:21 AM, Dagfinn Ilmari Mannsåker
wrote:
> How about "cannot cast jsonb $json_type to $sql_type" where $json_type
> is the type inside the jsonb (e.g. string, number, boolean, array,
> object)?
Yes, that sounds pretty good.
--
Robert Haas
EnterpriseDB: http://www.enterp
On 2018-05-07 13:52:26 -0400, Robert Haas wrote:
> On Sun, May 6, 2018 at 10:32 PM, Tatsuo Ishii wrote:
> > 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 j
On Fri, May 4, 2018 at 5:54 PM, Merlin Moncure wrote:
>> I mean, if you have a large number of sessions open, it's going to
>> take more memory in any design. If there are multiple sessions per
>> backend, there may be some possibility to save memory by allocating it
>> per-backend rather than pe
On Sun, May 6, 2018 at 10:32 PM, Tatsuo Ishii wrote:
> 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
On Sat, May 5, 2018 at 8:56 AM, Amit Kapila wrote:
> The reason why I think the current behavior is okay because it is
> coincidental that they were displayed correctly. We have not made any
> effort to percolate it to upper nodes. For ex., before that commit
> also, it was not being displayed f
In the wake of commit e89a71fb449af2ef74f47be1175f99956cf21524,
parallel.sgml is no longer correct about the effect of InitPlans:
The following operations are always parallel restricted.
...
Access to an InitPlan or correlated
SubPlan.
I thought about this a bit
On Sat, Apr 7, 2018 at 10:21 AM, Adrien Nayrat
wrote:
> I notice Parallel append is not listed on Parallel Plans documentation :
> https://www.postgresql.org/docs/devel/static/parallel-plans.html
I agree it might be nice to mention this somewhere on this page, but
I'm not exactly sure where it wo
I wrote:
> Thomas Munro writes:
>> Maybe we should do what the Perl people do[2] and post-process the
>> generated header file to add const qualifiers? Please see attached.
> +1 for the idea. I notice that Perl's version of this is careful
> not to munge lines that already contain "const" ... d
Robert Haas writes:
> On Fri, May 4, 2018 at 8:30 AM, Alexander Lakhin wrote:
>> I'm not seeing a workaround to perform more complete installcheck without
>> modifying makefiles. So for me the question is whether the increasing the
>> testing surface justifies this use of time.
> After thinking
On Sun, May 6, 2018 at 6:22 AM, Stas Kelvich wrote:
> Also each second GetSnapshotData writes globalxmin (as it was before
> procArray->global_snapshot_xmin was taken into account) into a circle
> buffer with a size equal to global_snapshot_defer_time value. That more
> or less the same thing as w
On Fri, May 4, 2018 at 8:30 AM, Alexander Lakhin wrote:
> I'm not seeing a workaround to perform more complete installcheck without
> modifying makefiles. So for me the question is whether the increasing the
> testing surface justifies this use of time.
After thinking about this some more, I thin
On Mon, May 07, 2018 at 07:26:25PM +0300, Alexander Korotkov wrote:
> Hi!
>
> I've revised docs and comments, and also made some fixes in the code.
> See the attached patchset.
>
> * 0004-btree-cleanup-docs-comments-fixes.patch
> Documentation and comment improvements from Justin Pryzby
> revised
2018-05-07 17:15 GMT+03:00 Robert Haas :
>
> On Sat, May 5, 2018 at 2:16 AM, Andrey Borodin
wrote:
> > But you loose difference between "touched once" and "actively used". Log
> > scale of usage solves this: usage count grows logarithmically, but
drains
> > linearly.
>
> Even if we have that, or s
Thomas Munro writes:
> --enable-dtrace produces compiler warnings about const correctness,
> except on macOS. That's because Apple's dtrace produces function
> declarations in probes.h that take strings as const char * whereas
> AFAIK on all other operating systems they take char * (you can see
>
Hi!
I've revised docs and comments, and also made some fixes in the code.
See the attached patchset.
* 0001-vacuum-cleanup-index-scale-factor-user-set.patch
Changes vacuum_cleanup_index_scale_factor GUC to PGC_USERSET,
because it might be useful to change in specific session.
* 0002-vacuum-clean
Ashutosh Bapat writes:
> Is there a way we can improve unnest() and array_agg() to match the
> performance you have specified by let's say optimizing the cases
> specially when those two are used together. Identifying that may be
> some work, but will not require introducing new syntax.
+1. The
On Sat, May 5, 2018 at 2:16 AM, Andrey Borodin wrote:
> But you loose difference between "touched once" and "actively used". Log
> scale of usage solves this: usage count grows logarithmically, but drains
> linearly.
Even if we have that, or something with similar effects, it's still
desirable to
2018-05-04 23:45 GMT+03:00 AJG :
>
> Another interesting article from Jan 2018 (Tsinghua University and
Microsoft
> Research)
>
> http://madsys.cs.tsinghua.edu.cn/publications/TS2018-liu.pdf
>
> DudeTx: Durable Transactions Made Decoupled
Cite from pdf:
> The key insight of our solution is decoup
On Fri, May 4, 2018 at 9:53 PM, Tsunakawa, Takayuki
wrote:
> Attached is a trivial documentation fix for PG 11 partitioning, which
> includes:
>
> * pg_partition fails to mention hash for the strategy.
> * Partitioning key column values can now be modified, which results in row
> movement betwee
On 25 April 2018 at 16:45, insaf.k wrote:
> Hello,
>
> I have developed a postgres extension in Linux. I want to compile it in MS
> Windows as well.
>
> The extension extensively make use of POSIX threads and mutexes.
>
> I've done some research regarding compiling in Windows. I am not sure in
> w
Greetings, insaf.k.
You wrote 25.04.2018, 11:45:
> Hello,
> I have developed a postgres extension in Linux. I want to compile it in MS
> Windows as well.
You should try MSYS2. It's far better than VS and MSYS right now.
I may try to build your extension if you want.
> The extension exten
Here is a documentation update from Liudmila Mantrova.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 4a68ec3..5bd7b45 100644
--- a/doc/src/sgml/maintenance.sgm
On Fri, May 4, 2018 at 6:38 PM, Ildar Musin wrote:
> Hello hackers,
>
> Recently I was working with sql arrays in postgres and it turned out
> that postgres doesn't have such very convinient functional constructions
> as map, reduce and filter. Currently to map function over array user has
> to ma
Hello hanckers,
We use this simple function to workaround citext=text behavior.
create extension citext;
CREATE FUNCTION citext_eq( citext, text )
RETURNS bool
AS 'citext'
LANGUAGE C IMMUTABLE STRICT;
CREATE OPERATOR = (
LEFTARG= CITEXT,
RIGHTARG = TEXT,
COMMUTATOR = =,
NE
Another interesting article from Jan 2018 (Tsinghua University and Microsoft
Research)
http://madsys.cs.tsinghua.edu.cn/publications/TS2018-liu.pdf
DudeTx: Durable Transactions Made Decoupled
"This paper presents DudeTx, a crash-consistent durable transaction system
that avoids the drawbacks of
On 04.05.2018 18:22, Merlin Moncure wrote:
On Thu, May 3, 2018 at 12:01 PM, Robert Haas wrote:
On Fri, Apr 27, 2018 at 4:43 PM, Merlin Moncure wrote:
What _I_ (maybe not others) want is a
faster pgbouncer that is integrated into the database; IMO it does
everything exactly right.
I have to
On 07.05.2018 11:58, Tatsuo Ishii wrote:
On 07.05.2018 05:32, Tatsuo Ishii wrote:
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 wonde
> On 07.05.2018 05:32, Tatsuo Ishii wrote:
>> 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
On 07.05.2018 11:24, Tsunakawa, Takayuki wrote:
From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
But I think it is better to start first with
1. Global prepared statements cache
2. Global catalog cache
3. Global relation cache
May I ask why prepared statements need to precede cata
On 07.05.2018 10:12, Konstantin Knizhnik wrote:
Concerning result cache, I think it will be better to ask opinion of
mysql users: how useful it is.
It isn't useful. I haven't seen a customer case in years where the query
cache would have done any good.
It is off by default ever since MySQL 5
From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
> But I think it is better to start first with
> 1. Global prepared statements cache
> 2. Global catalog cache
> 3. Global relation cache
May I ask why prepared statements need to precede catalog and relation caches?
We're suffering fr
On 07.05.2018 05:32, Tatsuo Ishii wrote:
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.
On 07.05.2018 08:23, Laurenz Albe wrote:
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
only help in certain cases and hurts in many others.
The MySQL query cache helped quite a bit in the earl
On Mon, May 07, 2018 at 10:37:10AM +0900, Michael Paquier wrote:
> 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
On 07-05-2018 4:37, Michael Paquier wrote:
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 ScalarArrayOpEx
> Having been bitten by the feature on MySQL, I think it's not a good thing.
Even in MySQL itself this feature was already removed.
>
>
>> Thanks for the input. It's worth noting that the equality operator
>> currently works in the same way: citext = text comparison is (surprisingly
>> for me) case-sensitive.
>>
>> My expectation was that since citext is supposed to be a case-insensitive
>> *type*, all comparison operations inv
On Sunday, May 6, 2018, Shay Rojansky wrote:
>
>
> Thanks for the input. It's worth noting that the equality operator
> currently works in the same way: citext = text comparison is (surprisingly
> for me) case-sensitive.
>
> My expectation was that since citext is supposed to be a case-insensitive
On 07/05/18 05:47, Tom Lane wrote:
Tatsuo Ishii writes:
Does anybody think having in-memory query result cache in core is a
good idea?
No.
Agreed.
You could probably write an extension for that, though. I think the
planner hook and custom scans give you enough flexibility to do that
with
50 matches
Mail list logo
