Hi
I have reported a bug via PostgreSQL bug report form, but havent got any
response so far.
This might not be a bug, but a feature not implemented yet.
I have created an suggestion to make a small addition to StartupXLOG.c to solve
the issue.
Any suggestions?
--
Leif Gunnar Erlandsen
On Wed, 23 Jan 2019 at 04:08, Alvaro Herrera wrote:
> Is it possible to avoid the special case for 0 columns by using the
> UNION ALL syntax I showed?
It would be possible, but my thoughts are that we're moving away from
the SQL standard by doing so.
Looking at the standard I see:
::=
[ {
hello,
I'm Maayan, I'm in a DBA team that uses postgresql.
I saw in the documentation on wals:
https://www.postgresql.org/docs/10/wal-intro.html
In the tip box that, it's better not to use a journaling filesystem. and I
wanted to ask how it works?
can't we get corruption that we can't recover
> "Andres" == Andres Freund writes:
[IDENTIFICATION]
Andres> I think we should just rip them out. It's useless noise.
+1
--
Andrew (irc:RhodiumToad)
> -Original Message-
> From: Michael Paquier [mailto:mich...@paquier.xyz]
> Sent: Wednesday, January 23, 2019 3:01 PM
> To: Moon, Insung
> Cc: 'Pg Hackers'
> Subject: Re: Typo: pgbench.c
>
> On Wed, Jan 23, 2019 at 02:18:49PM +0900, Moon, Insung wrote:
> > Attached fix it.
>
> Thanks,
On Wed, Jan 23, 2019 at 02:18:49PM +0900, Moon, Insung wrote:
> Attached fix it.
Thanks, pushed. Please note that the indentation was not correct
after applying your patch.
--
Michael
signature.asc
Description: PGP signature
Dear hackers.
I found a minor typo in the comment pgbench.c.
-* always allocate one more in order to accomodate the NULL
terminator
+* always allocate one more in order to accommodate the NULL
terminator
Attached fix it.
Regards.
Moon.
Isaac Morland writes:
> What is confusing me is why the planner can't convert "[entire row] IS
> NULL" into a test for existence of the matching row (assuming there is at
> least one NOT NULL column).
The reasons why the planner does very little with row-level IS [NOT] NULL
conditions are (1) so
On Tue, Jan 22, 2019 at 12:13 PM Oleg Bartunov wrote:
>
> On Tue, Jan 22, 2019 at 8:21 AM Alexander Korotkov
> wrote:
> >
> > The next revision is attached.
> >
> > Nikita made code and documentation improvements, renamed functions
> > from "jsonpath_" prefix to "jsonb_path_" prefix. He also
Michael Paquier writes:
> I am not sure if anybody uses them for anything automatically, still I
> find myself from time to time looking at them to remember on which
> path the file is located when opened in emacs. So I still like having
> those references, perhaps I am just a minority.
FWIW, I
On Fri, Jan 11, 2019 at 9:39 AM Dilip Kumar wrote:
>
> On Mon, Dec 31, 2018 at 11:04 AM Dilip Kumar wrote:
>>
>> On Tue, Dec 4, 2018 at 3:13 PM Dilip Kumar wrote:
>>
>> After the latest change in undo interface patch[1], this patch need to
>> be rebased. Attaching the rebased version of the
On Tue, Jan 22, 2019 at 11:21:32PM +, Bossart, Nathan wrote:
> On 1/21/19, 10:08 PM, "Michael Paquier" wrote:
> > On Mon, Jan 21, 2019 at 10:09:09PM +, Bossart, Nathan wrote:
> >> Here's a new patch set that should address the feedback in this
> >> thread. The changes in this version
On Tue, Jan 22, 2019 at 05:49:46PM -0800, Andres Freund wrote:
> On 2019-01-23 14:43:15 +1300, Thomas Munro wrote:
>> The function name comments are similar, though less consistent so I'm
>> too lazy to write a script to find one that is actually wrong (with
>> which to trigger Andres's
Dear Adrien,
> Hum, I am not an english native speaker, I choosed "rate" because it is
> already used for auto_explain.sample_rate and for log_statement_sample_rate
If the community agree those name, renaming parameters are not needed.
Consistency is the most important in a DBMS. :-)
I read
Hi Thomas,
On 2019/01/23 9:37, Thomas Munro wrote:
> On Wed, Jan 23, 2019 at 1:16 PM Amit Langote
> wrote:
>> On 2019/01/23 4:51, Andres Freund wrote:
>>> On 2019-01-22 13:43:32 +0900, Amit Langote wrote:
Attached find a patch to fix $subject.
>>>
>>> Thanks, pushed to master and 11.
>>
>>
Dear Hackers.
> -Original Message-
> From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com]
> Sent: Wednesday, January 23, 2019 9:38 AM
> To: Amit Langote
> Cc: Andres Freund; Pg Hackers
> Subject: Re: Typo: llvm*.cpp files identified as llvm*.c
>
> On Wed, Jan 23, 2019 at 1:16 PM
On 2019/01/22 18:47, David Rowley wrote:
> On Tue, 22 Jan 2019 at 20:01, Imai, Yoshikazu
>> What I understand so far is about 10,000 while loops at total
>> (4098+4098+some extra) is needed in hash_seq_search() in EXECUTE query after
>> the creation of the generic plan.
>> 10,000 while loops
On Wed, Jan 23, 2019 at 01:37:41PM +1300, Thomas Munro wrote:
> It's not only the ending that's wrong. Here are some more source
> files whose IDENTIFICATION heading doesn't exactly match their path:
Good point.
> $ git grep -A 1 IDENTIFICATION | grep -v IDENTIFICATION | grep -v --
> -- | sed
On 2019-01-23 14:43:15 +1300, Thomas Munro wrote:
> The function name comments are similar, though less consistent so I'm
> too lazy to write a script to find one that is actually wrong (with
> which to trigger Andres's let's-delete-them-all response :-D).
I wish function comment styles were more
On Wed, Jan 23, 2019 at 2:02 PM Andres Freund wrote:
> On 2019-01-23 09:55:22 +0900, Michael Paquier wrote:
> > On Wed, Jan 23, 2019 at 01:37:41PM +1300, Thomas Munro wrote:
> > > This could be really confusing for erm, future people reading a dot
> > > matrix print-out of the source code?
>
> I
Hi,
On 2019-01-23 09:55:22 +0900, Michael Paquier wrote:
> On Wed, Jan 23, 2019 at 01:37:41PM +1300, Thomas Munro wrote:
> > This could be really confusing for erm, future people reading a dot
> > matrix print-out of the source code?
I think we should just rip them out. It's useless noise.
>
On Tue, Jan 22, 2019 at 06:11:23PM -0300, Alvaro Herrera wrote:
> On 2019-Jan-22, Andres Freund wrote:
>> Largely because I think it's an independent patch from the CXXOPT need
>> from Christopher / Debian packaging. It's a larger patch, that needs
>> more docs etc. If whoever applies that wants
On Wed, Jan 23, 2019 at 1:16 PM Amit Langote
wrote:
> On 2019/01/23 4:51, Andres Freund wrote:
> > On 2019-01-22 13:43:32 +0900, Amit Langote wrote:
> >> Attached find a patch to fix $subject.
> >
> > Thanks, pushed to master and 11.
>
> Thank you.
It's not only the ending that's wrong. Here
On 1/22/19 10:00 AM, Surafel Temesgen wrote:
>
>
> On Mon, Jan 21, 2019 at 6:22 PM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
>
> I think the condition can be just
>
> if (contain_volatile_functions(cstate->whereClause)) { ... }
>
>
I've pushed a fix for
On 2019/01/23 4:51, Andres Freund wrote:
> Hi,
>
> On 2019-01-22 13:43:32 +0900, Amit Langote wrote:
>> Attached find a patch to fix $subject.
>
> Thanks, pushed to master and 11.
Thank you.
Regards,
Amit
On Wed, 23 Jan 2019 at 03:43, David Rowley wrote:
> I made another pass over the 0001 patch. I've not read through mcv.c
> again yet. Will try to get to that soon.
>
> 0001-multivariate-MCV-lists-20190117.patch
I started on mcv.c this morning. I'm still trying to build myself a
picture of how it
On Wed, Jan 23, 2019 at 4:07 AM Tom Lane wrote:
> Thomas Munro writes:
> > Hmm. Why is psql doing two sendto() calls without reading a response
> > in between, when it's possible for the server to exit after the first,
> > anyway? Seems like a protocol violation somewhere?
>
> Keep in mind
On Tue, 22 Jan 2019 at 15:32, Andrew Gierth
wrote:
> > "Isaac" == Isaac Morland writes:
>
> Isaac> So it is as if checking the whole tuple for NULL requires
> Isaac> reading the PDF bytea columns, but checking just the primary key
> Isaac> for NULL or even reading the lengths of the PDFs
On Sat, 12 Jan 2019 at 23:42, David Rowley wrote:
> I've attached a rebase version of this. The previous version
> conflicted with some changes made in b60c397599.
I've attached another rebased version. This one fixes up the conflict
with e0c4ec07284.
--
David Rowley
Hello
On 2019-Jan-22, Andres Freund wrote:
> On 2019-01-22 17:10:58 -0300, Alvaro Herrera wrote:
> > I don't understand why you don't want to backpatch the PGXS bits.
>
> Largely because I think it's an independent patch from the CXXOPT need
> from Christopher / Debian packaging. It's a
Hi,
On 2019-01-22 14:53:11 -0600, Kevin Grittner wrote:
> On Tue, Jan 22, 2019 at 2:38 PM Andres Freund wrote:
>
> > close() doesn't trigger an fsync() in general
>
> What sort of a performance hit was observed when testing the addition
> of fsync or fdatasync before any PostgreSQL close() of
On Tue, Jan 22, 2019 at 2:38 PM Andres Freund wrote:
> close() doesn't trigger an fsync() in general
What sort of a performance hit was observed when testing the addition
of fsync or fdatasync before any PostgreSQL close() of a writable
file, or have we not yet checked that?
>
On Tue, Jan 22, 2019 at 11:42:35AM -0800, Andres Freund wrote:
> Hi,
>
> On 2019-01-22 11:08:40 -0800, Donald Dong wrote:
> > In the standard_planner, we set the proper JIT flags on the resulting
> > PlannedStmt node. We also offered a planer hook so extensions can
> > add customized planners.
Hi,
On 2019-01-22 14:29:23 -0600, Kevin Grittner wrote:
> On Tue, Jan 22, 2019 at 12:17 PM Andres Freund wrote:
>
> > Unfortunately, unless something has changed recently, that patch is
> > *not* sufficient to really solve the issue - we don't guarantee that
> > there's always an fd preventing
Hello Tom,
Here is a POC which defines an internal interface for a PRNG, and use it
within pgbench, with several possible implementations which default to
rand48.
I seriously dislike this patch. pgbench's random support is quite
overengineered already IMO, and this proposes to add a whole
On Wed, Jan 23, 2019 at 9:29 AM Kevin Grittner wrote:
> Can you point to a post explaining how the inode can be evicted?
Hi Kevin,
To recap the (admittedly confusing) list of problems with Linux fsync
or our usage:
1. On Linux < 4.13, the error state can be cleared in various
surprising ways
> "Isaac" == Isaac Morland writes:
Isaac> So it is as if checking the whole tuple for NULL requires
Isaac> reading the PDF bytea columns, but checking just the primary key
Isaac> for NULL or even reading the lengths of the PDFs does not.
That is almost certainly exactly what happens. If
On Tue, Jan 22, 2019 at 12:17 PM Andres Freund wrote:
> Unfortunately, unless something has changed recently, that patch is
> *not* sufficient to really solve the issue - we don't guarantee that
> there's always an fd preventing the necessary information from being
> evicted from memory:
But we
Hi,
On 2019-01-22 17:10:58 -0300, Alvaro Herrera wrote:
> On 2019-Jan-22, Andres Freund wrote:
>
> > I think its plain wrong to add COPT to CXXFLAGS. Re PROFILE I'm on the
> > fence. I personally think the pgxs stuff is a bit separate, and I'm
> > doubtful we ought to backpatch that. I'm
On 2019-Jan-22, Andres Freund wrote:
> I think its plain wrong to add COPT to CXXFLAGS. Re PROFILE I'm on the
> fence. I personally think the pgxs stuff is a bit separate, and I'm
> doubtful we ought to backpatch that. I'm basically planning to apply
>
Greetings,
* Vikramsingh Kushwaha (vskushw...@mitaoe.ac.in) wrote:
> I, Vikramsingh Kushwaha, currently studying in B.Tech 3rd year computer
> engineering in MIT Pune, India. I am very much interested to contribute in
> the open source projects. But i am new to this so I needed some guidance.
>
On 2019-01-22 15:26:21 +0900, Michael Paquier wrote:
> On Thu, Jan 17, 2019 at 02:55:39PM +0900, Michael Paquier wrote:
> > Personally I see pgxs as something completely different than what COPT
> > and PROFILE are as we are talking about two different facilities: one
> > which is part of the core
-- Forwarded message -
From: Vikramsingh Kushwaha
Date: Mon, Jan 21, 2019 at 11:56 PM
Subject: Fwd: Google Summer Of Code
To:
-- Forwarded message -
From: Vikramsingh Kushwaha
Date: Mon, Jan 21, 2019 at 11:54 PM
Subject: Fwd: Google Summer Of Code
To:
It's not demonstrably slower than 2.5 either. (1.1 is measurably slower;
probably not by enough for anyone to care, but 1.5 is good enough for me.)
Good if it fails quick enough for you.
Attached a patch with the zipf doc update & the TAP test parameter change.
--
Fabien.diff --git
Hi,
On 2019-01-22 13:43:32 +0900, Amit Langote wrote:
> Attached find a patch to fix $subject.
Thanks, pushed to master and 11.
Greetings,
Andres Freund
Hi,
On 2019-01-22 11:08:40 -0800, Donald Dong wrote:
> In the standard_planner, we set the proper JIT flags on the resulting
> PlannedStmt node. We also offered a planer hook so extensions can
> add customized planners. The JIT flags in jit/jit.h however, is
> not present on the system. I think
Hi
fresh rebased patch, no other changes
Pavel
schema-variables-20190122-01.patch.gz
Description: application/gzip
On 1/22/19 7:36 PM, Arthur Zakirov wrote:
> пн, 21 янв. 2019 г. в 19:42, Arthur Zakirov :
>>
>> On 21.01.2019 17:56, Tomas Vondra wrote:
>>> I wonder if we could devise some simple cache eviction policy. We don't
>>> have any memory limit GUC anymore, but maybe we could use unload
>>>
Hi,
On 2019-01-21 19:41:26 -0500, Tom Lane wrote:
> Andres Freund writes:
> > It'd be more
> > realistic to create a new zone at UINT32_MAX - something, but that'd
> > likely still conflict in plenty installations (thanks to toast and WITH
> > OIDS tables). I'm curious as to how to solve that,
Hi,
In the standard_planner, we set the proper JIT flags on the resulting
PlannedStmt node. We also offered a planer hook so extensions can
add customized planners. The JIT flags in jit/jit.h however, is
not present on the system. I think it's probably better to
install the jit headers?
diff
The first value is taken about 75% of the time for N=1000 and s=2.5, which
means that a non deterministic implementation would succeed about 0.75² ~
56% of the time on that one.
Right, that's about what we've been seeing on OpenBSD.
Also, the drawing procedure is less efficient when the
пн, 21 янв. 2019 г. в 19:42, Arthur Zakirov :
>
> On 21.01.2019 17:56, Tomas Vondra wrote:
> > I wonder if we could devise some simple cache eviction policy. We don't
> > have any memory limit GUC anymore, but maybe we could use unload
> > dictionaries that were unused for sufficient amount of
Hi,
On 2019-01-22 18:35:21 +0100, Tomas Vondra wrote:
> On 1/21/19 11:15 PM, Tomas Vondra wrote:
> > On 1/21/19 7:51 PM, Andres Freund wrote:
> >> I'm *not* convinced by this. I think it's bad enough that we do this for
> >> normal COPY, but for WHEN, we could end up *never* resetting before the
Hi,,
On 2019-01-22 08:27:48 -0600, Kevin Grittner wrote:
> With the help of VMware's Dirk Hohndel (VMware's Chief Open Source
> Officer, a VP position near the top of the organization, and a
> personal friend of Linus), I have been fortunate enough to make
> contact directly with Linus Torvalds
út 22. 1. 2019 v 14:55 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> There are still a handful of places where a statement is created but no
> stmtid is assigned. Can you check those?
>
> src/pl/plpgsql/src/pl_exec.c:2815
> src/pl/plpgsql/src/pl_exec.c:4580
>
These
On January 22, 2019 9:50:19 AM PST, Andrew Dunstan
wrote:
>
>On 1/21/19 10:00 PM, Andrew Dunstan wrote:
>> On 1/21/19 3:25 PM, Tom Lane wrote:
>>> "Joshua D. Drake" writes:
On 1/21/19 12:05 PM, Tom Lane wrote:
> Is there a newer version of mingw that does have this
>functionality?
On 1/21/19 10:00 PM, Andrew Dunstan wrote:
> On 1/21/19 3:25 PM, Tom Lane wrote:
>> "Joshua D. Drake" writes:
>>> On 1/21/19 12:05 PM, Tom Lane wrote:
Is there a newer version of mingw that does have this functionality?
>>> Apparently this can be done with thee 64bit version:
>>>
I'm finding a massive difference in query execution time between two
queries that should be identical:
Very slow:
select ... from x natural left join y where y is null
Fast:
select ... from x natural left join y where y.primary_key_column is null
A fact that I suspect is important is that y has
On 1/21/19 11:15 PM, Tomas Vondra wrote:
>
>
> On 1/21/19 7:51 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2019-01-21 16:22:11 +0100, Tomas Vondra wrote:
>>>
>>>
>>> On 1/21/19 4:33 AM, Tomas Vondra wrote:
On 1/21/19 3:12 AM, Andres Freund wrote:
> On 2019-01-20 18:08:05 -0800,
Fabien COELHO writes:
>> I'm not following this argument. The test case is basically useless
>> for its intended purpose with that parameter, because it's highly
>> likely that the failure mode it's supposedly checking for will be
>> masked by the "random" function's tendency to spit out the
> > This comment seems wrong:
> >
> > + * However weak implication fails: e.g., "NULL IS NOT NULL" is false, but
> > + * "NULL = ANY(ARRAY[NULL])" is NULL, so non-falsity does not imply
> > non-falsity.
> >
> > "non-falsity does not imply non-falsity"? I suppose one of those
> > negations should
On Tue, Jan 22, 2019 at 4:26 AM Alvaro Herrera wrote:
>
> Hello, I gave this patch a very quick scan. I didn't check the actual
> logic behind it.
>
> This comment seems wrong:
>
> + * However weak implication fails: e.g., "NULL IS NOT NULL" is false, but
> + * "NULL = ANY(ARRAY[NULL])" is NULL,
The cfbot reports this patch no longer applies.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello Surafel,
okay .thank you for explaining. i attach a patch corrected as such
About this v9: applies cleanly, compiles, global and local "make check"
ok.
The option is not exercise in the TAP tests. I'd suggest that it should be
tested on a small table with zero, 1, more than the
Nice stuff.
Is it possible to avoid the special case for 0 columns by using the
UNION ALL syntax I showed?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Thomas Munro writes:
> Hmm. Why is psql doing two sendto() calls without reading a response
> in between, when it's possible for the server to exit after the first,
> anyway? Seems like a protocol violation somewhere?
Keep in mind this is all down inside the SSL handshake, so if any
protocol
On Fri, Jan 18, 2019 at 3:13 PM Andres Freund wrote:
> TestForOldSnapshot()
> to me it seems wrong from a layering POV to have this in
> bufmgr.[ch]. Due to the inline functions this makes bufmgr.h have a
> dependency on snapmgr.h and tqual.h, which to me seems wrong from a
> layer POV. Why
On Fri, 18 Jan 2019 at 10:03, Tomas Vondra wrote:
> thanks for the review. The attached patches address most of the issues
> mentioned in the past several messages, both in the MCV and histogram parts.
I made another pass over the 0001 patch. I've not read through mcv.c
again yet. Will try to
On Tue, Jan 22, 2019 at 8:27 AM Kevin Grittner wrote:
> With the help of VMware's Dirk Hohndel (VMware's Chief Open Source
> Officer, a VP position near the top of the organization, and a
> personal friend of Linus), I have been fortunate enough to make
> contact directly with Linus Torvalds to
With the help of VMware's Dirk Hohndel (VMware's Chief Open Source
Officer, a VP position near the top of the organization, and a
personal friend of Linus), I have been fortunate enough to make
contact directly with Linus Torvalds to discuss this issue. In emails
to me he has told me that this
There are still a handful of places where a statement is created but no
stmtid is assigned. Can you check those?
src/pl/plpgsql/src/pl_exec.c:2815
src/pl/plpgsql/src/pl_exec.c:4580
src/pl/plpgsql/src/pl_gram.y:907
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL
On Tue, Jan 22, 2019 at 3:35 PM David Rowley
wrote:
> On Sat, 19 Jan 2019 at 01:01, Surafel Temesgen
> wrote:
> > if you specified --inserts option you already specified the number of
> rows per statement which is 1 .
> > if more than one rows per statement needed it must be specified using
>
On Fri, Jan 18, 2019 at 11:42 PM Masahiko Sawada
wrote:
> On Fri, Jan 18, 2019 at 10:38 AM Haribabu Kommi
> wrote:
> >
> >
> > On Tue, Jan 15, 2019 at 6:00 PM Masahiko Sawada
> wrote:
> >>
> >>
> >> Rebased.
> >
> >
> > I started reviewing the patch, I didn't finish my review yet.
> >
BEGIN;
UPDATE pgbench_branches SET bbalance = bbalance + 1 RETURNING * \g /bad
// the update is performed, the transaction is not rollbacked,
// *but* the output file was not written, "COMMIT" save changes.
if PQexec() could not store the results for lack of memory, it would
yield a
On Sat, 19 Jan 2019 at 01:01, Surafel Temesgen wrote:
> if you specified --inserts option you already specified the number of rows
> per statement which is 1 .
> if more than one rows per statement needed it must be specified using
> --rows-per-insert
> and specifying one row per statement
Fabien COELHO wrote:
> > Now if you download data with SELECT or COPY and we can't even
> > create the file, how is that a good idea to intentionally have the
> > script fail to detect it? What purpose does it satisfy?
>
> It means that the client knows that the SQL command, and possible
Let me remind the thread.
If no more comments, objections, or better ideas, please commit this fix.
Thanks,
2019年1月17日(木) 18:29 Kyotaro HORIGUCHI :
>
> Hello, sorry for the absence.
>
> At Fri, 11 Jan 2019 11:36:43 -0500, Robert Haas wrote
> in
> > On Thu, Jan 10, 2019 at 9:10 PM Kohei KaiGai
> "Tom" == Tom Lane writes:
>> 1. easier to read and maintain
Tom> The SQL-level API that I'm imagining would look roughly like
Tom> a command like this at the end of an extension's script:
Tom> ALTER EXTENSION extname SET MAP
Tom> OBJECT 1 IS FUNCTION foo(int, int),
Tom> OBJECT
(Moving this discussion from the pgsql-committers thread "pgsql:
Update ssl test certificates and keys", which is innocent.)
On Wed, Jan 16, 2019 at 10:37 AM Thomas Munro
wrote:
> On Fri, Jan 4, 2019 at 10:08 AM Thomas Munro
> wrote:
> > Thanks. FWIW I've just updated eelpout (a Debian testing
On Tue, 22 Jan 2019 at 15:29, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Mon, Jan 21, 2019 at 9:33 AM Amit Khandekar
> > wrote:
> >
> > Regression tests that use \d+ to show the table details might
> > not be interested specifically in table access method. But these will
> > fail if run
- works around pgbench command splitting on spaces,
if postgres sources are in a strangely named directory…
I tested within a directory named "pg .* dir".
I've also tested it with the initial case (including a +) and it works.
Good, thanks for checking!
--
Fabien.
Hello, I gave this patch a very quick scan. I didn't check the actual
logic behind it.
This comment seems wrong:
+ * However weak implication fails: e.g., "NULL IS NOT NULL" is false, but
+ * "NULL = ANY(ARRAY[NULL])" is NULL, so non-falsity does not imply
non-falsity.
"non-falsity does not
Hi,
> - works around pgbench command splitting on spaces,
>if postgres sources are in a strangely named directory…
>I tested within a directory named "pg .* dir".
I've also tested it with the initial case (including a +) and it works.
--
Raúl Marín Rodríguez
carto.com
Hello Tom,
BTW, did you look at the question of the range of zipfian?
Yep.
I confirmed here that as used in the test case, it's generating a range way
smaller than the other ones: repeating the insertion snippet 1000x produces
stats like this: [...]
I have no idea whether that
> On Mon, Jan 21, 2019 at 3:01 AM Andres Freund wrote:
>
> The patchset is now pretty granularly split into individual pieces.
Wow, thanks!
> On Mon, Jan 21, 2019 at 9:33 AM Amit Khandekar wrote:
>
> Regression tests that use \d+ to show the table details might
> not be interested specifically
On Tue, 22 Jan 2019 at 20:01, Imai, Yoshikazu
wrote:
> I didn't use it yet, but I just used perf to clarify the difference of before
> and after the creation of the generic plan, and I noticed that usage of
> hash_seq_search() is increased about 3% in EXECUTE queries after the creation
> of
On Tue, Jan 22, 2019 at 8:21 AM Alexander Korotkov
wrote:
>
> The next revision is attached.
>
> Nikita made code and documentation improvements, renamed functions
> from "jsonpath_" prefix to "jsonb_path_" prefix. He also renamed
> jsonpath_predicate() to jsonb_path_match() (that looks better
On Tue, Jan 22, 2019 at 2:17 PM Michael Paquier wrote:
>
> On Tue, Jan 22, 2019 at 01:47:05PM +0900, Masahiko Sawada wrote:
> > Or can we make the test script set force_parallel_mode = off? Since
> > the failure case is a very rare in real world I think that it might be
> > better to change the
On Mon, Jan 21, 2019 at 6:22 PM Tomas Vondra
wrote:
>
> I think the condition can be just
>
> if (contain_volatile_functions(cstate->whereClause)) { ... }
>
>
>
yes it can be.
regards
Surafel
>
>
> Thoughts?
I have a feeling this is over-engineering in slightly different direction,
solving the way for hack to work instead of original problem.
What's currently happening in PostGIS is that there are functions that need
to perform index-based lookups.
Postgres is unable to plan this
Hello Tom,
I did a little bit of googling on this subject last night, and it
seems that at least some people believe that the answer is to not
use glob, period, but read the directory for yourself.
As a short-term move to un-break the buildfarm, I'm just going to
revert that patch altogether.
Hi all,
While working on REINDEX CONCURRENTLY, I have noticed that
index_build() does not need its argument isprimary. Perhaps it is
not worth bothering, but for the REINDEX CONCURRENTLY business this
removes the need to open an index when triggering a concurrent
build.
The flag was introduced
92 matches
Mail list logo
