On Tue, Jan 1, 2019 at 10:08 PM Tomas Vondra
wrote:
> The execution part of the patch seems to be working correctly, but I
> think there's an improvement - we don't need to execute the outer plan
> to completion before emitting the first row. For example, let's say the
> outer plan produces 1
On Thu, Jan 3, 2019 at 4:51 PM Tomas Vondra
wrote:
>
> On 1/3/19 1:00 PM, Surafel Temesgen wrote:
> > Hi
> >
> > On Tue, Jan 1, 2019 at 10:08 PM Tomas Vondra
> > mailto:tomas.von...@2ndquadrant.com>>
> wrote:
>
> > The execution part of the patch seems to be working correctly, but I
> > t
> Attached patches implementing all SQL/JSON functions excluding
JSON_TABLE:
>
> JSON_OBJECT()
> JSON_OBJECTAGG()
> JSON_ARRAY()
> JSON_ARRAYAGG()
>
> JSON_EXISTS()
> JSON_VALUE()
> JSON_QUERY()
Sorry if this is a stupid question, but is this patch intended to
implement any SQL/JSON functions?
I tried to make a patch to have dual hooks at set_rel_pathlist(), and
adjusted PG-Strom for the new design. It stopped to create GatherPath
by itself, just added a partial path for the base relation.
It successfully made a plan using parallel custom-scan node, without
system crash.
As I mentioned
On Fri, Jan 4, 2019 at 8:23 AM Mithun Cy wrote:
> Thanks,
>
> On Sun, Dec 30, 2018 at 3:49 AM John Naylor wrote:
> > On 12/29/18, Mithun Cy wrote:
> > > Results are execution time(unit ms) taken by copy statement when number of
> > > records equal to exact number which fit HEAP_FSM_CREATION_THR
Hi,
On 2019-01-04 08:54:34 +0530, Amit Kapila wrote:
> On Thu, Jan 3, 2019 at 11:30 PM Andres Freund wrote:
> > On 2018-12-31 09:56:48 +0530, Amit Kapila wrote:
> > > To support logical decoding for zheap operations, we need a way to
> > > ensure zheap tuples can be registered as change streams.
On Thu, Jan 3, 2019 at 11:30 PM Andres Freund wrote:
>
> Hi,
>
> On 2018-12-31 09:56:48 +0530, Amit Kapila wrote:
> > To support logical decoding for zheap operations, we need a way to
> > ensure zheap tuples can be registered as change streams. One idea
> > could be that we make ReorderBufferCh
On Fri, 4 Jan 2019 at 13:01, Tomas Vondra wrote:
> On 1/3/19 11:57 PM, David Rowley wrote:
> > You'll know you're getting a generic plan when you see "Filter (a =
> > $1)" and see "Subplans Removed: " below the Append.
> >
>
> Indeed, with prepared statements I now see some improvements:
>
>
John Naylor writes:
> Since it's been a few months since last discussion, I'd like to
> summarize the purpose of this patch and advocate for its inclusion in
> v12:
Pushed after some review and correction. Notably, I didn't like
leaving the info about the encoding lookup out of bki.sgml, so
I ch
On 1/3/19 11:57 PM, David Rowley wrote:
> On Fri, 4 Jan 2019 at 11:48, Tomas Vondra
> wrote:
>> Nope, that doesn't seem to make any difference :-( In all cases the
>> resulting plan (with 10k partitions) looks like this:
>>
>> test=# explain analyze select * from hashp where a = 13442;
>>
>>
On 03/01/2019 23:22, Daniel Heath wrote:
> I propose a 'titletext' type, which has the following properties when
> compared for equality:
> * Case insensitivity (like 'citext')
> * Only considers characters in [:alnum:] (that is, ignores spaces,
> punctuation, etc)
My work on insensitive/non-det
Em qui, 3 de jan de 2019 às 20:53, Daniel Heath escreveu:
> Would this also be appropriate for inclusion as contrib? I'm unfamiliar
> with the policy for what is / is not included there.
>
>
Please do not top post.
At first I recommend you implement it as an extension (using gitlab,
github, bitb
Updated patches for some merge conflicts
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 296d8d19cc49c2e7a6e8489a6d21cd6a182f2686 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 2 Oct 2018 12:17:22
On 2018-Nov-06, LAM JUN RONG wrote:
> Hi,
>
> I must have forgotten to change the diff.
I noticed that you edited the diff by hand -- the line count in the last
hunk doesn't match. This causes both "path" and "git apply" to reject
the patch saying it's corrupted. I suggest not to do that. I c
On Fri, 4 Jan 2019 at 11:48, Tomas Vondra wrote:
> Nope, that doesn't seem to make any difference :-( In all cases the
> resulting plan (with 10k partitions) looks like this:
>
> test=# explain analyze select * from hashp where a = 13442;
>
> QUERY PLAN
>
Would this also be appropriate for inclusion as contrib? I'm unfamiliar
with the policy for what is / is not included there.
Thanks,
Daniel Heath
On Fri, Jan 4, 2019, at 9:47 AM, Fabrízio de Royes Mello wrote:
>
>
> Em qui, 3 de jan de 2019 às 20:22, Daniel Heath
> escreveu:>> Hi All,
>>
>> I
On 1/3/19 10:50 PM, David Rowley wrote:
> On Fri, 4 Jan 2019 at 02:40, Tomas Vondra
> wrote:
>> I'm a bit confused, because I can't reproduce any such speedup. I've
>> used the attached script that varies the number of partitions (which
>> worked quite nicely in the INSERT thread), but I'm gettin
Em qui, 3 de jan de 2019 às 20:22, Daniel Heath escreveu:
> Hi All,
>
> I've frequently seen an issue in applications which store titles (eg of
> books, events, user profiles) where duplicate values are not properly
> vetted.
>
> The 'citext' type is helpful here, but I'd be keen to go further.
>
Hi All,
I've frequently seen an issue in applications which store titles (eg of books,
events, user profiles) where duplicate values are not properly vetted.
The 'citext' type is helpful here, but I'd be keen to go further.
I propose a 'titletext' type, which has the following properties when
Hi,
On 2019-01-03 17:03:43 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 03/01/2019 22:01, Tom Lane wrote:
> >> while ereport(ERROR) has the
> >> effect of writing a message and then calling exit(1).
>
> > The problem is that in majority of cases the FRONTEND code, as it is
> > writte
Peter Eisentraut writes:
> On 03/01/2019 22:01, Tom Lane wrote:
>> while ereport(ERROR) has the
>> effect of writing a message and then calling exit(1).
> The problem is that in majority of cases the FRONTEND code, as it is
> written today, doesn't want to exit() after an error.
Right, so for th
On Fri, 4 Jan 2019 at 02:40, Tomas Vondra wrote:
> I'm a bit confused, because I can't reproduce any such speedup. I've
> used the attached script that varies the number of partitions (which
> worked quite nicely in the INSERT thread), but I'm getting results like
> this:
>
> partitions 0
Updated patch for some merge conflicts and addressing most of your
comments. (I did not do anything about the syntax.)
On 09/12/2018 19:55, Sergei Kornilov wrote:
> I found one error in phase 4. Simple reproducer:
>
>> create table test (i int);
>> create index this_is_very_large_exactly_maxname
On 03/01/2019 22:01, Tom Lane wrote:
> I envisioned that we'd have a wrapper in which
> non-error ereports() map directly onto what you're calling
> pg_log_debug, pg_log_warning, etc,
My code does that, but the other way around. (It's easier that way than
to unpack ereport() invocations.)
> whil
Attached version 7, with some renaming and rewording of comments.
(I also pgindented. Some things are not pretty because of lack of
typedefs.list patching ... a minor issue at worst.)
I'm still not satisfied with the way the builtin enum tables are passed.
Can we settle for using add_enum_relopti
On Fri, Jan 4, 2019 at 3:36 AM Peter Eisentraut
wrote:
> On 23/12/2018 09:04, Michael Paquier wrote:
> > On Tue, Nov 27, 2018 at 02:21:39PM +, Peter Eisentraut wrote:
> >> Update ssl test certificates and keys
> >>
> >> Debian testing and newer now require that RSA and DHE keys are at
> >> lea
Peter Eisentraut writes:
> On 03/01/2019 19:03, Andres Freund wrote:
>>> Relatedly, rewriting all the frontend programs to exception style would
>>> end up being a 10x project to rewrite everything for no particular
>>> benefit. Going from 8 or so APIs to 2 is already an improvement, I
>>> think.
On 2019-Jan-03, Nikolay Shaplov wrote:
> Can we think about backward compatibility aliases?
>
> #define ViewHasCheckOption(relation) \
> ((relation)->rd_options && \
> ((ViewOptions *) (relation)->rd_options)->che
On Mon, Dec 31, 2018 at 2:23 PM Adam Brightwell <
adam.brightw...@crunchydata.com> wrote:
>
> > * Solution #2 - Quick and dirty and invisible. Tom suggested a hack that
> achieves the aims of #1 but without adding syntax to CREATE FUNCTION: have
> the inlining logic look at the cost of the wrapper
В письме от четверг, 3 января 2019 г. 16:10:20 MSK пользователь Alvaro Herrera
написал:
> On 2019-Jan-02, Nikolay Shaplov wrote:
> > This is internal API, right? If we change it everywhere, then it is
> > changed and nothing will be broken?
>
> No, it's exported for extensions to use. If we chan
On 2019-Jan-02, Nikolay Shaplov wrote:
> This is internal API, right? If we change it everywhere, then it is changed
> and nothing will be broken?
No, it's exported for extensions to use. If we change it unnecessarily,
extension authors will hate me (not you) for breaking the compile and
requir
Peter Eisentraut writes:
> On 02/01/2019 20:47, Jesper Pedersen wrote:
>
>> Well, that really depends. The user passed -j to pg_upgrade in order for
>> the upgrade to happen faster, so maybe they would expect, as I would,
>> that the ANALYZE phase would happen in parallel too.
>
> pg_upgrade -j
On 03/01/2019 19:03, Andres Freund wrote:
>> My goal was to make logging smaller and more
>> compact. Two, I think tying error reporting to flow control does not
>> always work well and leads to bad code and a bad user experience.
>
> Not sure I can buy that, given that we seem to be doing quite
Cool, thanks!
> 2 янв. 2019 г., в 20:35, Heikki Linnakangas написал(а):
>
> In patch #1, to do the vacuum scan in physical order:
> ...
> I think this is ready to be committed, except that I didn't do any testing.
> We discussed the need for testing earlier. Did you write some test scripts
> f
I noticed that this patch has broken restores of existing dump files:
psql:testbed.public.backup:82: ERROR: unrecognized configuration parameter
"default_with_oids"
Quite aside from the fact that this won't work if the user tries to
restore in single-transaction or no-error mode, this is really
On 2019-Jan-03, Andres Freund wrote:
> Hi,
>
> On 2019-01-03 15:13:42 -0300, Alvaro Herrera wrote:
> > Hmm, without looking at the patches, I agree that the tuples should be
> > given as slots to the logical decoding interface. I wonder if we need a
> > further function in the TTS interface to
Hi,
On 2019-01-03 15:13:42 -0300, Alvaro Herrera wrote:
> On 2019-Jan-03, Andres Freund wrote:
>
> > > Apart from this, we need to define different decode functions for
> > > zheap operations as the WAL data is different for heap and zheap, so
> > > same functions can't be used to decode.
> >
>
On 2019-Jan-03, Andres Freund wrote:
> > Apart from this, we need to define different decode functions for
> > zheap operations as the WAL data is different for heap and zheap, so
> > same functions can't be used to decode.
>
> I'm very strongly opposed to that. We shouldn't have expose every
> p
Hi,
On 2019-01-03 14:28:51 +0100, Peter Eisentraut wrote:
> On 31/12/2018 16:55, Andres Freund wrote:
> > I think we should aim to unify the use (in contrast to the
> > implementation) of logging as much as possible, rather than having a
> > separate API for it for client programs.
>
> I opted ag
Hi,
On 2018-12-31 09:56:48 +0530, Amit Kapila wrote:
> To support logical decoding for zheap operations, we need a way to
> ensure zheap tuples can be registered as change streams. One idea
> could be that we make ReorderBufferChange aware of another kind of
> tuples as well, something like this
Peter Eisentraut writes:
> On 29/11/2018 16:34, Tom Lane wrote:
>> After sleeping on it for awhile, I am liking the idea of probing
>> python, python3, python2 (while keeping the $PYTHON override of
>> course).
> I think this was the option with the most support. Here is a patch.
> I agree we ca
I revised this patch a bit. Here's v25, where some finishing touches
are needed -- see below. I think with these changes the patch would
become committable, at least for me.
I didn't like that you were adding an #include of psqlscan_int.h into
pgbench.c, when there's a specific comment in the he
> Attached 21st version of the patches.
>
> I decided to include here patch with complete jsonpath
implementation (it
> is a squash of all 6 jsonpath-v21 patches). I hope this will simplify
reviewing
> and testing in cfbot.cputube.org.
I'd like to help in reviewing this patch. Please let
On Sun, Dec 16, 2018 at 11:50:15AM -0500, John Naylor wrote:
> A few months ago I was looking into faster search algorithms for
> ScanKeywordLookup(), so this is interesting to me. While an optimal
> full replacement would be a lot of work, the above ideas are much less
> invasive and would still h
> As a general rule, it's wise to do "make distclean" before "git pull"
> when you're tracking master. This saves a lot of grief when someone
> rearranges the set of generated files, as happened here. (If things
> are really messed up, you might need "git clean -dfx" to get rid of
> everything no
Daniel Gustafsson writes:
>> On 3 Jan 2019, at 16:54, Chapman Flack wrote:
>> Perhaps influenced by commit 842cb9f ?
> It is indeed related to that commit. You will need to do make distclean, or
> remove dynloader.h manually.
As a general rule, it's wise to do "make distclean" before "git pull
> On 3 Jan 2019, at 16:54, Chapman Flack wrote:
>
> On 1/3/19 10:47 AM, Andrew Alsup wrote:
>> cp ./*.h '/usr/local/pgsql/include/server'/
>> cp: ./dynloader.h: No such file or directory
>
> Has dynloader.h somehow ended up as a symbolic link to a file
> no longer present?
>
> Perhaps influence
On 1/3/19 10:47 AM, Andrew Alsup wrote:
> cp ./*.h '/usr/local/pgsql/include/server'/
> cp: ./dynloader.h: No such file or directory
Has dynloader.h somehow ended up as a symbolic link to a file
no longer present?
Perhaps influenced by commit 842cb9f ?
-Chap
I am unable to `make install` on MacOS in the latest master (68a13f28be).
Here are the steps to reproduce.
OS: MacOSX 10.14.2
Branch: master:HEAD (68a13f28be)
$ git log --pretty=format:'%h' -n 1
68a13f28be
$ ./configure --with-bonjour
$ make
$ sudo make install
...
/usr/bin/install -c -m 644 uti
Hi,
I don't think I can't help with code review, but I loaded our largest
customer's schema into pg12dev and tested with this patch. It's working well -
thanks for your work.
Details follow.
We have tooo many tables+indices so this vastly improves planning speed. Our
large customers have ~300
On 23/12/2018 09:04, Michael Paquier wrote:
> On Tue, Nov 27, 2018 at 02:21:39PM +, Peter Eisentraut wrote:
>> Update ssl test certificates and keys
>>
>> Debian testing and newer now require that RSA and DHE keys are at
>> least 2048 bit long and no longer allow SHA-1 for signatures in
>> cert
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> So I'd like to get to a point where we're comfortable marking these
> >> functions leakproof despite the possibility of corner-case failures.
> >> We could just decide that th
On 29/11/2018 16:34, Tom Lane wrote:
> After sleeping on it for awhile, I am liking the idea of probing
> python, python3, python2 (while keeping the $PYTHON override of
> course).
I think this was the option with the most support. Here is a patch.
I agree we can backport this.
--
Peter Eisent
On 1/3/19 1:00 PM, Surafel Temesgen wrote:
> Hi
>
> On Tue, Jan 1, 2019 at 10:08 PM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
> ...
>
> Firstly, the estimated number of rows should be about the same (10k) in
> both cases, but the "percent" case incorrectly uses
On 12/3/18 12:42 PM, David Rowley wrote:
> ...
>
> Master: 1 parts
>
> $ pgbench -n -f bench.sql -M prepared -T 60 postgres
> tps = 108.882749 (excluding connections establishing)
> tps = 108.245437 (excluding connections establishing)
>
> delaylock: 1 parts
>
> $ pgbench -n -f bench.sql
On 31/12/2018 16:55, Andres Freund wrote:
> I think we should aim to unify the use (in contrast to the
> implementation) of logging as much as possible, rather than having a
> separate API for it for client programs.
I opted against doing that, for mainly two reasons: One, I think the
ereport() AP
On 30/12/2018 20:45, Tom Lane wrote:
> It seems like a shame that src/common files still need to have
> #ifdef FRONTEND variant code to deal with frontend vs. backend
> conventions. I wonder how hard it would be to layer some subset of
> ereport() functionality on top of what you have here, so as
I've just looked over the v4 patch. I agree that having an RTE for a
from-less SELECT seems like a good idea.
While reading the patch, I noted the following:
1. It's more efficient to use bms_next_member as it does not need to
re-skip 0 words on each iteration. (Likely bms_first_member() is not
n
Hi,
On 11/23/18 1:14 AM, David Rowley wrote:
> As a follow-on from [1] and also discussed in [2], I'd like to propose
> that we don't obtain locks on all partitions during INSERT into a
> partitioned table and UPDATE of a partitioned key and instead, only
> lock the partition when we first route a
On 02/01/2019 20:47, Jesper Pedersen wrote:
> Well, that really depends. The user passed -j to pg_upgrade in order for
> the upgrade to happen faster, so maybe they would expect, as I would,
> that the ANALYZE phase would happen in parallel too.
pg_upgrade -j reduces the *downtime* caused by pg_
Hi
On Tue, Jan 1, 2019 at 10:08 PM Tomas Vondra
wrote:
> Hi,
>
> I've been looking at this patch today, and I think there's a couple of
> issues with the costing and execution. Consider a simple table with 1M
> rows:
>
> create table t as select i from generate_series(1,100) s(i);
>
> and
On 02/01/2019 23:53, Alexey Bashtanov wrote:
>> In fact, maybe don't use the Portal structure at all and just store the
>> saved textualized values inside postgres.c in a static variable.
>
> Unlike SQL, parameters may spend much more memory, so I'd have them
> in portal memory context to make sur
В письме от среда, 2 января 2019 г. 8:59:13 MSK пользователь James Coleman
написал:
> > So I decided to write it down to a wiki article, while I am restoring the
> > configuration so I do not have to remember them for the third time, if I
> > loose .vimrc again. :-)
>
> I like expanding the smal
On 03/01/2019 12:15, Nikolay Shaplov wrote:
>> +1, let's keep it simple. I would just use "ctags/etags not found"
>> as error message.
>
> Actually I was trying to say "Please install 'ctags' [utility] to run
> make_ctags". But if all of you read it as "Please install 'ctags' [package]
> to
>
On 03/01/2019 10:39, Christoph Berg wrote:
> It will especially say which _alternate.out file was used, which seems
> like a big win. So +1.
It already shows that in the existing diff output header.
Although if you have a really long absolute path, it might be hard to
find it. So perhaps the att
В письме от четверг, 3 января 2019 г. 10:03:53 MSK пользователь Michael
Paquier написал:
> On Wed, Jan 02, 2019 at 11:35:46AM -0500, Tom Lane wrote:
> > In fact, that's demonstrably not so: on my RHEL6 and Fedora boxes,
> > /usr/bin/etags isn't owned by any package, because it's a symlink
> > mana
On 02/01/2019 21:44, Tom Lane wrote:
> Peter Eisentraut writes:
>> While we're considering the pg_regress output, what do you think about
>> replacing the ==... separator with a standard diff separator like
>> "diff %s %s %s\n". This would make the file behave more like a proper
>> diff file,
> On 3 Jan 2019, at 10:39, Christoph Berg wrote:
>
> Re: Peter Eisentraut 2019-01-02
> <70440c81-37bb-76dd-e48b-b5a9550d5...@2ndquadrant.com>
>> While we're considering the pg_regress output, what do you think about
>> replacing the ==... separator with a standard diff separator like
>> "di
Re: Peter Eisentraut 2019-01-02
<70440c81-37bb-76dd-e48b-b5a9550d5...@2ndquadrant.com>
> Committed.
\o/
> While we're considering the pg_regress output, what do you think about
> replacing the ==... separator with a standard diff separator like
> "diff %s %s %s\n". This would make the file
69 matches
Mail list logo
