On Sat, Dec 2, 2017 at 3:54 PM, Thomas Munro
wrote:
> On Sat, Dec 2, 2017 at 1:55 PM, Andres Freund wrote:
>> - As we don't clean temp files after crash-restarts it isn't impossible
>> to have a bunch of crash-restarts and end up with pids *and* per-pid
>> shared file set counters reused. Whi
On 2017-11-27 22:25:12 +1300, Thomas Munro wrote:
> On Thu, Nov 23, 2017 at 12:36 AM, Thomas Munro
> wrote:
> > Here's a new patch set with responses to the last batch of review comments.
Looking at 0004-Add-shared-tuplestores.patch
Comments:
- I'd rename mutex to lock. Seems quite possible that
On Sat, Dec 2, 2017 at 1:55 PM, Andres Freund wrote:
> Pushed 0003-Add-infrastructure-for-sharing-temporary-files-betwe.patch
> after minor adjustments (some including conversing with you).
Thank you!
> Questions:
> - Right now RemovePgTempFilesInDir() will recurse into appropriately
> named d
Hi,
On 2017-11-27 22:25:12 +1300, Thomas Munro wrote:
Pushed 0003-Add-infrastructure-for-sharing-temporary-files-betwe.patch
after minor adjustments (some including conversing with you).
Changes:
- Changed an impossible elog() into an Assert().
- changed SharedFileSet->counter, and the backend st
On Fri, Dec 1, 2017 at 11:55 PM, Peter Eisentraut
wrote:
> On 11/30/17 00:36, Michael Paquier wrote:
>> On Wed, Nov 29, 2017 at 1:04 AM, Peter Eisentraut
>> wrote:
>>> On 11/22/17 21:08, Michael Paquier wrote:
Yes, agreed. This patch looks good to me. In fe-auth-scram.c, it would
be als
Hello Robert,
The fact that the return type is not consistently of one type bothers
me. I'm not sure pgbench's expression language is a good place to
runtime polymorphism -- SQL doesn't work that way.
Sure.
Pg has a NUMERIC adaptative precision version, which is cheating, because
it can re
On 2017-12-01 17:03:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-12-01 16:40:23 -0500, Tom Lane wrote:
> >> I have no faith in either of these proposals, because they both assume
> >> that the problem only arises over the course of many minutes. In the
> >> recent complaint about
Andres Freund writes:
> On 2017-12-01 16:40:23 -0500, Tom Lane wrote:
>> I have no faith in either of these proposals, because they both assume
>> that the problem only arises over the course of many minutes. In the
>> recent complaint about pg_dump causing relcache bloat, it probably does
>> not
Pavel Stehule writes:
> 2017-12-01 16:36 GMT+01:00 Robert Haas :
>> I vote to reject this patch. It doesn't do anything that you can't
>> already do; it just adds some syntactic sugar. And that syntactic
>> sugar saves only a handful of keystrokes. If you want unaligned,
>> tuples-only mode, yo
On Fri, 1 Dec 2017 16:38:42 -0300
Alvaro Herrera wrote:
>
> To me it makes sense to say "let's create this method which is for
> data compression" (CREATE ACCESS METHOD hyperz TYPE COMPRESSION)
> followed by either "let's use this new compression method for the
> type tsvector" (ALTER TYPE tsvec
On 2017-12-01 16:14:58 -0500, Robert Haas wrote:
> Honestly, if we can give everybody a 4% space reduction by switching
> to lz4, I think that's totally worth doing -- but let's not make
> people choose it, let's make it the default going forward, and keep
> pglz support around so we don't break pg
On 2017-12-01 16:40:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-12-01 16:20:44 -0500, Robert Haas wrote:
> >> Well, yeah, that would be insane. But I think even something very
> >> rough could work well enough. I think our goal should be to eliminate
> >> cache entries that are
Andres Freund writes:
> On 2017-12-01 16:20:44 -0500, Robert Haas wrote:
>> Well, yeah, that would be insane. But I think even something very
>> rough could work well enough. I think our goal should be to eliminate
>> cache entries that are have gone unused for many *minutes*, and
>> there's no
On 2017-12-01 16:20:44 -0500, Robert Haas wrote:
> Well, yeah, that would be insane. But I think even something very
> rough could work well enough. I think our goal should be to eliminate
> cache entries that are have gone unused for many *minutes*, and
> there's no urgency about getting it to a
On Thu, Nov 30, 2017 at 11:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Nov 29, 2017 at 11:17 PM, Tom Lane wrote:
>>> The thing that makes me uncomfortable about this is that we used to have a
>>> catcache size limitation mechanism, and ripped it out because it had too
>>> much overhe
On 12/01/2017 08:38 PM, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> On 11/30/2017 09:51 PM, Alvaro Herrera wrote:
>
>>> Just passing by, but wouldn't this fit in the ACCESS METHOD group of
>>> commands? So this could be simplified down to
>>> CREATE ACCESS METHOD ts1 TYPE COMPRESSION
>>> w
On 12/1/17, 3:04 PM, "Robert Haas" wrote:
> On Fri, Dec 1, 2017 at 1:53 PM, Bossart, Nathan wrote:
>> There is already an internal flag called VACOPT_NOWAIT that gives
>> autovacuum this ability in certain cases (introduced in the aforementioned
>> commit), and I recently brought up this potentia
On Fri, Dec 1, 2017 at 4:06 PM, Tomas Vondra
wrote:
>>> I agree with these thoughts in general, but I'm not quite sure
>>> what is your conclusion regarding the patch.
>>
>> I have not reached one. Sometimes I like to discuss problems before
>> deciding what I think. :-)
>
> That's lame! Let's mak
On Sat, Dec 2, 2017 at 4:08 AM, Peter Eisentraut
wrote:
> On 11/30/17 23:35, Thomas Munro wrote:
>> On Fri, Dec 1, 2017 at 5:04 PM, Justin Pryzby wrote:
>>> On Fri, Dec 01, 2017 at 04:01:24PM +1300, Thomas Munro wrote:
Hi hackers,
The manual implies that only Linux can use huge pag
On Fri, Dec 1, 2017 at 2:38 PM, Alvaro Herrera wrote:
> In mine, they define how things are accessed (i.e. more general than
> what you're thinking). We *currently* use them to store rows [in
> indexes], but there is no reason why we couldn't expand that.
>
> So we group access methods in "types"
On 12/01/2017 08:20 PM, Robert Haas wrote:
> On Fri, Dec 1, 2017 at 10:18 AM, Tomas Vondra
> wrote:
>> It has very little impact on this patch, as it has nothing to do with
>> columnar storage. That is, each value is compressed independently.
>
> I understand that this patch is not about columnar
On Fri, Dec 1, 2017 at 1:53 PM, Bossart, Nathan wrote:
> There is already an internal flag called VACOPT_NOWAIT that gives
> autovacuum this ability in certain cases (introduced in the aforementioned
> commit), and I recently brought up this potential use-case as
> justification for a patch [0].
On 12/01/2017 08:48 PM, Alvaro Herrera wrote:
> Ildus Kurbangaliev wrote:
>
>> If the table is big, decompression could take an eternity. That's why i
>> decided to only to disable it and the data could be decompressed using
>> compression options.
>>
>> My idea was to keep compression options f
On Fri, Dec 1, 2017 at 1:28 PM, Robert Haas wrote:
> [ lots of minor comments ]
When I took a break from sitting at the computer, I realized that I
think this has a more serious problem: won't it permanently leak
reference counts if someone hits ^C or an error occurs while the lock
is held? I th
On Fri, Dec 1, 2017 at 2:48 PM, Peter Eisentraut
wrote:
> Here is a new patch, now on top of master. The main changes are that a
> lot of documentation has been added.
This feature doesn't have many tests. I think it should have a lot
more of them. It's tinkering with the transaction control m
On Fri, Dec 1, 2017 at 11:29 AM, Bossart, Nathan wrote:
> Thanks for the review, Robert. I've attached a new version that
> addresses your feedback.
Thanks. I think this looks fine now, except that (1) it needs a
pgindent run and (2) I vote for putting the test case back. Michael
thought the t
Ildus Kurbangaliev wrote:
> If the table is big, decompression could take an eternity. That's why i
> decided to only to disable it and the data could be decompressed using
> compression options.
>
> My idea was to keep compression options forever, since there will not
> be much of them in one da
On 11/14/17 18:38, Peter Eisentraut wrote:
> On 10/31/17 15:38, Peter Eisentraut wrote:
>> Here is a patch that implements transaction control in PL/Python
>> procedures. (This patch goes on top of "SQL procedures" patch v1.)
>
> Here is an updated patch, now on top of "SQL procedures" v2.
Here
Tomas Vondra wrote:
> On 11/30/2017 09:51 PM, Alvaro Herrera wrote:
> > Just passing by, but wouldn't this fit in the ACCESS METHOD group of
> > commands? So this could be simplified down to
> > CREATE ACCESS METHOD ts1 TYPE COMPRESSION
> > we have that for indexes and there are patches flying f
On Fri, Dec 1, 2017 at 10:18 AM, Tomas Vondra
wrote:
> It has very little impact on this patch, as it has nothing to do with
> columnar storage. That is, each value is compressed independently.
I understand that this patch is not about columnar storage, but I
think the idea that we may want to op
On Fri, Dec 1, 2017 at 10:04 AM, Chapman Flack wrote:
> Can I call RegisterDynamicBackgroundWorker when not in the postmaster,
> but also not in a "regular backend", but rather another BGW?
I believe that doing it from another BGW works fine.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
On Fri, Dec 1, 2017 at 7:41 AM, Ashutosh Bapat
wrote:
> This code creates plans where there are multiple Gather nodes under an Append
> node.
We should avoid that. Starting and stopping workers is inefficient,
and precludes things like turning the Append into a Parallel Append.
> AFAIU, the wor
On Fri, Dec 1, 2017 at 6:20 AM, Beena Emerson wrote:
> David Q1:
> postgres=# explain analyse execute ab_q1 (3,3); --const
>QUERY PLAN
> -
> App
On Fri, Dec 1, 2017 at 4:57 AM, Raúl Marín Rodríguez
wrote:
> I've rebased the patch so it can be applied cleanly on top of current
> master.
Please add the new function into the documentation table in alphabetical order.
The fact that the return type is not consistently of one type bothers
me.
On Fri, Dec 1, 2017 at 5:13 AM, Ashutosh Bapat
wrote:
> partition_bounds_equal() accesses the last datum from the given
> partition bounds directly to compare their greatest moduli. Rest of
> the code uses get_greatest_modulus() to get the greatest modulus from
> a partition bound. partition_bound
On 12/1/17, 11:16 AM, "Tomas Vondra" wrote:
>> The behavior I would like to see is that the void ignores this table and
>> moves to another instead of being blocked.
>>
>
> I believe autovacuum should not block waiting for a heavy-weight lock on
> a table since this commit that went into 9.1:
>
On Fri, Dec 1, 2017 at 4:01 AM, Antonin Houska wrote:
> I see no other problems here.
Committed, thanks for the report and review.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
A few very minor comments while quickly paging through:
1. non-ASCII tests are going to cause problems in one platform or
another. Please don't include that one.
2. error messages
a) please use ereport() not elog()
b) conform to style guidelines: errmsg() start with lowercase, others
On Fri, Dec 1, 2017 at 10:14 AM, Masahiko Sawada wrote:
> The patched is 10 times faster than current HEAD.
Nifty.
The first hunk in monitoring.sgml looks unnecessary.
The second hunk breaks the formatting of the documentation; you need
to adjust the "morerows" value from 9 to 8 here:
Robert Haas writes:
> On Fri, Dec 1, 2017 at 12:30 AM, Michael Paquier
> wrote:
>> Patch moved to CF 2018-01. Perhaps a committer will look at it at some point.
> FWIW, although I like the idea, I'm not going to work on the patch. I
> like Perl, but I neither know its internals nor use plperl.
On Fri, Dec 1, 2017 at 2:44 AM, Amit Langote
wrote:
> I forgot to consider the fact that mtstate could be NULL in
> ExecSetupPartitionTupleRouting(), so would result in dereferencing NULL
> pointer when called from CopyFrom(), which fixed in the attached updated
> patch.
a ? b : false can more si
On 30/11/17 11:48, Simon Riggs wrote:
> On 30 November 2017 at 11:30, Petr Jelinek
> wrote:
>> On 30/11/17 00:47, Andres Freund wrote:
>>> On 2017-11-30 00:45:44 +0100, Petr Jelinek wrote:
I don't understand. I mean sure the SnapBuildWaitSnapshot() can live
with it, but the problematic
On Fri, Dec 1, 2017 at 1:36 AM, Rajkumar Raghuwanshi
wrote:
> On Tue, Oct 31, 2017 at 2:45 PM, Robert Haas wrote:
>>> OK, committed. This is a good example of how having good code
>> coverage doesn't necessarily mean you've found all the bugs. :-)
>>
> As of now partition_join.sql is not having
On Fri, Dec 1, 2017 at 12:31 AM, Michael Paquier
wrote:
> I am moving this patch to next CF 2018-01.
There now seems to be a consensus for superuser -> superuser_arg
rather than what Jeff did originally; that approach has 4 votes and
nothing else has more than 1. So, here's a patch that does it t
On Fri, Dec 1, 2017 at 12:30 AM, Michael Paquier
wrote:
> On Tue, Nov 28, 2017 at 5:14 PM, Aleksander Alekseev
> wrote:
>> The new status of this patch is: Ready for Committer
>
> Patch moved to CF 2018-01. Perhaps a committer will look at it at some point.
FWIW, although I like the idea, I'm no
On 2 December 2017 at 01:31, Peter Eisentraut
wrote:
> On 11/30/17 15:50, Thomas Munro wrote:
>> postgres=# \df
>>List of functions
>> Schema | Name | Result data type | Argument data types | Type
>> +--+--+-+--
>> publi
On Fri, Dec 1, 2017 at 12:21 AM, Michael Paquier
wrote:
> On Wed, Sep 13, 2017 at 4:07 PM, Ashutosh Bapat
> wrote:
>> For a partitioned table, this patch saves the time to run constraint
>> exclusion on all the partitions if constraint exclusion succeeds on
>> the partitioned table. If constraint
2017-12-01 16:36 GMT+01:00 Robert Haas :
> On Fri, Dec 1, 2017 at 12:16 AM, Michael Paquier
> wrote:
> > On Sat, Nov 11, 2017 at 12:57 AM, Pavel Stehule
> wrote:
> >> 2017-11-10 16:38 GMT+01:00 Fabien COELHO :
> >>> So I switched the patch to "ready for committer".
> >>
> >> Thank you very much
src/tools/msvc/builddoc.pl and the associated documentation (in
install-windows.sgml) is quite outdated, even for PG10. If someone has
the required knowledge, please consider supplying an update.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, R
On Fri, Dec 1, 2017 at 12:16 AM, Michael Paquier
wrote:
> On Sat, Nov 11, 2017 at 12:57 AM, Pavel Stehule
> wrote:
>> 2017-11-10 16:38 GMT+01:00 Fabien COELHO :
>>> So I switched the patch to "ready for committer".
>>
>> Thank you very much
>
> Patch moved to CF 2018-01 with same status: ready f
On 12/01/2017 03:23 PM, Robert Haas wrote:
> On Thu, Nov 30, 2017 at 2:47 PM, Tomas Vondra
> wrote:
>> OK. I think it's a nice use case (and nice gains on the compression
>> ratio), demonstrating the datatype-aware compression. The question is
>> why shouldn't this be built into the datatypes dire
On Fri, Dec 1, 2017 at 10:26 AM, Masahiko Sawada wrote:
> On Fri, Dec 1, 2017 at 3:04 AM, Robert Haas wrote:
>> On Thu, Nov 30, 2017 at 6:20 AM, Masahiko Sawada
>> wrote:
This code ignores the existence of multiple databases; RELEXTLOCK
contains a relid, but no database OID. That's e
On Fri, Dec 1, 2017 at 9:31 AM, Peter Eisentraut
wrote:
> On 11/30/17 15:50, Thomas Munro wrote:
>> postgres=# \df
>>List of functions
>> Schema | Name | Result data type | Argument data types | Type
>> +--+--+-+--
>> pu
On 11/30/17 23:35, Thomas Munro wrote:
> On Fri, Dec 1, 2017 at 5:04 PM, Justin Pryzby wrote:
>> On Fri, Dec 01, 2017 at 04:01:24PM +1300, Thomas Munro wrote:
>>> Hi hackers,
>>>
>>> The manual implies that only Linux can use huge pages. That is not
>>> true: FreeBSD, Illumos and probably others
On Thu, Nov 30, 2017 at 11:54 PM, Amit Langote
wrote:
>> I have added a CF entry for this thread by the way
>> (https://commitfest.postgresql.org/16/1392/), and marked the thing as
>> ready for committer as we agree about the fix. Let's track properly
>> this issue until it gets committed.
>
> Yea
On 11/29/2017 05:48 PM, Chapman Flack wrote:
> I'm thinking of writing a background worker that will enumerate
> the databases present, and spin off, for each one, another BGW
> that will establish a connection and do stuff.
Can I even do this?
"Unlike RegisterBackgroundWorker, which can only be
On 11/30/17 00:36, Michael Paquier wrote:
> On Wed, Nov 29, 2017 at 1:04 AM, Peter Eisentraut
> wrote:
>> On 11/22/17 21:08, Michael Paquier wrote:
>>> Yes, agreed. This patch looks good to me. In fe-auth-scram.c, it would
>>> be also nice to add a comment to keep in sync the logics in
>>> build_c
On Thu, Nov 30, 2017 at 11:39 PM, David Rowley
wrote:
> I feel like we could do better here with little extra effort. The
> DETACH index feature does not really seem required for this patch.
Because of the dump/restore considerations mentioned in
http://postgr.es/m/ca+tgmobuhghg9v8saswkhbbfywg5a0
On Sun, Nov 26, 2017 at 3:15 AM, Amit Kapila wrote:
> Yeah and I think something like that can happen after your patch
> because now the memory for tuples returned via TupleQueueReaderNext
> will be allocated in ExecutorState and that can last for long. I
> think it is better to free memory, but
On Fri, Dec 1, 2017 at 1:58 AM, Alvaro Herrera wrote:
> On a *very* quick look, please use an enum to return from NextCopyFrom
> rather than 'int'. The chunks that change bool to int are very
> odd-looking. This would move the comment that explains the value from
> copy.c to copy.h, obviously.
On 11/30/17 15:50, Thomas Munro wrote:
> postgres=# \df
>List of functions
> Schema | Name | Result data type | Argument data types | Type
> +--+--+-+--
> public | bar | integer | i integer | func
> p
On 11/21/17 05:16, Martín Marqués wrote:
> El 21/11/17 a las 04:56, Arthur Zakirov escribió:
>> On Mon, Nov 20, 2017 at 04:45:48PM -0300, Martín Marqués wrote:
>>> New version of patch, without the --batch-mode option and using isatty()
>>>
>>
>> Great!
>>
>>> + fprintf(stderr, "waiting f
On Thu, Nov 30, 2017 at 2:47 PM, Tomas Vondra
wrote:
> OK. I think it's a nice use case (and nice gains on the compression
> ratio), demonstrating the datatype-aware compression. The question is
> why shouldn't this be built into the datatypes directly?
Tomas, thanks for running benchmarks of thi
On 11/30/2017 09:51 PM, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> On 11/30/2017 04:20 PM, Ildus Kurbangaliev wrote:
>
>>> CREATE COMPRESSION METHOD ts1 FOR tsvector HANDLER
>>> tsvector_compression_handler;
>>
>> Understood. Good to know you've considered it, and I agree it doesn't
>> ne
On Thu, Nov 30, 2017 at 10:04 PM, Michael Paquier
wrote:
> On Wed, Nov 8, 2017 at 12:54 AM, Fabrízio de Royes Mello
> wrote:
>> Great. Changed status to ready for commiter.
>
> The patch still applies, but no committer seem to be interested in the
> topic, so moved to next CF.
The general idea o
Here is a v13. No code changes, but TAP tests added to maintain pgbench
coverage to green.
Here is a v14, which is just a rebase after the documentation xml-ization.
Regenerated v15 that applies cleanly on head. No changes.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml
Continuing with review of 0007.
+
+/* Copy input rels's relids to grouped rel */
+grouped_rel->relids = input_rel->relids;
Isn't this done in fetch_upper_rel()? Why do we need it here?
There's also a similar hunk in create_grouping_paths() which doesn't look
appropriate. I guess, you need
Hello,
PFA the updated patch rebased over Amit's v13 patches [1] part of
which is committed. This also fixes few bugs I found.
The InitPlans require execPlan which is not set during ExecInitAppend
and so the evaluation of extern quals is moved from ExecInitAppend to
ExecAppend. This changes the ou
Hi Fabien,
The idea is that it would be relative to the "more functions and operators"
> patch, but I guess this is too much for people checking, so I'm fine with
> having it with the current base.
>
I tried applying the last "more functions and operators" patch
(pgbench-more-ops-funcs-14.patch)
Hello Raúl,
I've rebased the patch so it can be applied cleanly on top of current
master.
The idea is that it would be relative to the "more functions and
operators" patch, but I guess this is too much for people checking, so I'm
fine with having it with the current base.
Patch applies cl
Hi all,
partition_bounds_equal() accesses the last datum from the given
partition bounds directly to compare their greatest moduli. Rest of
the code uses get_greatest_modulus() to get the greatest modulus from
a partition bound. partition_bounds_equal() should also do the same
for the sake of cons
Hi,
I've rebased the patch so it can be applied cleanly on top of current
master.
On Fri, Dec 1, 2017 at 3:55 AM, Michael Paquier
wrote:
> On Tue, Nov 7, 2017 at 1:34 AM, Fabien COELHO wrote:
> > Let's now hope that a committer gets around to consider these patch some
> > day.
>
> Which is not
Jeevan Chalke wrote:
> On Thu, Nov 30, 2017 at 3:44 PM, Jeevan Chalke
> wrote:
>
> On Thu, Nov 30, 2017 at 1:36 AM, Antonin Houska wrote:
>
> The following test
>
> -- Input relation to aggregate push down hook is not safe to pushdown and
> thus
> -- the aggregate cannot be pushed down
Alexander Korotkov wrote:
> On Wed, Nov 22, 2017 at 1:22 PM, Antonin Houska wrote:
>
> Alexander Korotkov wrote:
>
> > Antonin Houska wrote:
>
> > > * ExecIncrementalSort()
> > >
> > > ** if (node->tuplesortstate == NULL)
> > >
> > > If both branches contain the expression
> > >
>
74 matches
Mail list logo
