On Sat, May 26, 2018 at 6:33 PM Amit Kapila wrote:
> On Fri, Mar 2, 2018 at 4:05 PM, Alexander Korotkov
> wrote:
>
> It's been a while since we have updated the progress on this project,
> so here is an update.
>
Yet, another update.
> This is based on the features that were not
> working (as
On Thu, Nov 01, 2018 at 01:32:09AM +0100, Andreas 'ads' Scherbaum wrote:
> Picking up on this idea, attached is a first draft for changing the
> README.
Why don't you add it to the upcoming commit fest? It would be good to
get some traction with a formal review.
> It includes links to the websit
On Tue, Oct 23, 2018 at 10:43:38AM +0900, Michael Paquier wrote:
> Well, following the same kind of thoughts, txid_current_snapshot() uses
> sort_snapshot() to remove all the duplicates after fetching its data
> from GetSnapshotData(), so wouldn't we want to do something about
> removal of duplicat
Excuse me for being noisy.
Increasing vacuum's ring buffer improves vacuum upto 6 times.
https://www.postgresql.org/message-id/flat/20170720190405.GM1769%40tamriel.snowman.net
This is one-line change.
How much improvement parallel vacuum gives?
31.10.2018 3:23, Masahiko Sawada пишет:
> On Tue, O
On 01/11/2018 14:30, David Rowley wrote:
On 1 November 2018 at 13:35, Amit Langote wrote:
On 2018/11/01 8:58, David Rowley wrote:
[...]
I agree. I don't think "TupRouting" really needs to be in the name.
Probably "To" can also just become "2" and we can put back the
Parent/Child before that
On Thu, Nov 01, 2018 at 12:39:16PM +0900, Amit Langote wrote:
> Rajkumar pointed out off-list that the patch still remains to be applied.
> Considering that there is a planned point release on Nov 8, maybe we
> should do something about this?
Yes doing something about that very soon would be a goo
On 2018/11/01 13:02, Michael Paquier wrote:
> On Thu, Nov 01, 2018 at 12:58:29PM +0900, Amit Langote wrote:
>> Attached find a patch that does such refactoring, along with making some
>> functions in partbounds.c that are not needed outside static.
>
> This looks like a very good idea to me. Than
On Thu, Nov 01, 2018 at 12:58:29PM +0900, Amit Langote wrote:
> Attached find a patch that does such refactoring, along with making some
> functions in partbounds.c that are not needed outside static.
This looks like a very good idea to me. Thanks for digging into that.
Please just make sure to r
Hi,
Currently, the code that creates a PartitionBoundInfo struct from the
PartitionBoundSpec nodes of constituent partitions read from the catalog
is in RelationBuildPartitionDesc that's in partcache.c. I think that
da6f3e45dd that moved around the partitioning code [1] really missed the
opportun
On 2018/09/14 10:53, Amit Langote wrote:
> On 2018/09/13 23:13, Tom Lane wrote:
>> Amit Langote writes:
>>> On 2018/09/13 1:14, Tom Lane wrote:
That seems excessively restrictive. Anything that has storage (e.g.
matviews) ought to be truncatable, no?
>>
>>> Not by heap_truncate it seems
Thanks for looking at this.
On 1 November 2018 at 16:07, Steve Singer wrote:
> --- a/doc/src/sgml/perform.sgml
> +++ b/doc/src/sgml/perform.sgml
> @@ -1534,9 +1534,10 @@ SELECT * FROM x, y, a, b, c WHERE something AND
> somethingelse;
> TRUNCATE command. In such cases no WAL
> needs to
[ just when you thought it was safe to go back in the water ]
I wrote:
>> Jakob Egger writes:
>>> I would assume that clang sets -isysroot automatically, but I have no idea
>>> why that didn't work for you previously.
>> [ experiments further ... ] It looks like clang does default to assuming
On 1 November 2018 at 04:01, Antonin Houska wrote:
> * As for the logic, I found generate_mergeappend_paths() to be the most
> interesting part:
>
> Imagine table partitioned by "i", so "partition_pathkeys" is {i}.
>
> partition 1:
>
> i | j
> --+--
> 0 | 0
> 1 | 1
> 0 | 1
> 1 | 0
>
> partition
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, failed
--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@
On 11/1/18, Nasby, Jim wrote:
> Hmm… 18 bytes doesn’t sound right, at least not for the Datum. Offhand I’d
> expect it to be the small (1 byte) varlena header + an OID (4 bytes). Even
> then I don’t understand how 1600 text columns would work; the data area of a
> tuple should be limited to ~2000
On 1 November 2018 at 12:24, Andres Freund wrote:
> FWIW, I kind of wonder if we built proper infrastructure to allow to
> make such inferrences from function calls, whether it could also be made
> to support the transformation of LIKEs into indexable <= >= clauses.
Perhaps, but I doubt it would
On 1 November 2018 at 13:35, Amit Langote wrote:
> On 2018/11/01 8:58, David Rowley wrote:
>> On 1 November 2018 at 06:45, Robert Haas wrote:
>>> I think a better way to shorten the name would be to truncate the
>>> PartitionTupRouting() prefix in some way, e.g. dropping TupRouting.
>>
>> Thanks
On Wed, Oct 31, 2018 at 01:09:53PM -0400, Robert Haas wrote:
> There's no rule whatsoever that a parallel worker can't write to the
> disk. pg_start_backup and pg_stop_backup have to be
> parallel-restricted because, when used in non-exclusive mode, they
> establish backend-local state that wouldn
On Wed, Oct 31, 2018 at 11:21:33PM +, Nasby, Jim wrote:
> On Oct 11, 2018, at 10:35 AM, David Fetter wrote:
> >
> >> It didn't get far, but you may want to take a look at a rejected patch for
> >> copy_srf() (set returning function)
> >> https://www.postgresql.org/message-id/CADkLM%3DdoeiWQX4
On Wed, Oct 31, 2018 at 01:30:52PM -0400, Robert Haas wrote:
> In theory, at least, you could write C code to scan the catalog tables
> with SnapshotDirty to find the catalog entries, but I don't think that
> helps a whole lot. You couldn't necessarily rely on those catalog
> entries to be in a co
On 2018/11/01 8:58, David Rowley wrote:
> On 1 November 2018 at 06:45, Robert Haas wrote:
>> On Wed, Aug 22, 2018 at 8:30 AM David Rowley
>> wrote:
>>> On 22 August 2018 at 19:08, Amit Langote
>>> wrote:
+#define PartitionTupRoutingGetToParentMap(p, i) \
+#define PartitionTupRoutingGe
HI Andres,
On Wed, Oct 31, 2018 at 03:48:02PM -0700, Andres Freund wrote:
> And done. Thanks for the report JD.
Shouldn't we also switch the PANIC to a FATAL in RestoreSlotFromDisk()?
I don't mind doing so myself if you agree with the change, only on
HEAD as you seemed to disagree about changing
On 01.11.18 01:29, Michael Paquier wrote:
On Wed, Oct 31, 2018 at 08:30:40AM -0400, Stephen Frost wrote:
Agreed, we should really improve the README by merging the README.git
into it and make the project, as a whole, more accessible to new
developers.
+1. I think as well that this approach wou
Hi,
On 2018-11-01 09:29:37 +0900, Michael Paquier wrote:
> On Wed, Oct 31, 2018 at 08:30:40AM -0400, Stephen Frost wrote:
> > Agreed, we should really improve the README by merging the README.git
> > into it and make the project, as a whole, more accessible to new
> > developers.
>
> +1. I think
Em qua, 28 de fev de 2018 às 20:03, Euler Taveira
escreveu:
> The attached patches add support for filtering rows in the publisher.
>
I rebased the patch. I added row filtering for initial
synchronization, pg_dump support and psql support. 0001 removes unused
code. 0002 reduces memory use. 0003 pa
On Wed, Oct 31, 2018 at 08:30:40AM -0400, Stephen Frost wrote:
> Agreed, we should really improve the README by merging the README.git
> into it and make the project, as a whole, more accessible to new
> developers.
+1. I think as well that this approach would be a good thing.
--
Michael
signat
On 1 November 2018 at 06:45, Robert Haas wrote:
> On Wed, Aug 22, 2018 at 8:30 AM David Rowley
> wrote:
>> On 22 August 2018 at 19:08, Amit Langote
>> wrote:
>> > +#define PartitionTupRoutingGetToParentMap(p, i) \
>> > +#define PartitionTupRoutingGetToChildMap(p, i) \
>> >
>> > If the "Get" cou
Hi,
On 2018-11-01 12:19:32 +1300, David Rowley wrote:
> On 1 November 2018 at 12:11, Tomas Vondra
> wrote:
> > I still have trouble imagining what exactly would the function do to
> > determine if the optimization can be applied to substr() and similar
> > collation-dependent cases.
>
> I guess
On Oct 11, 2018, at 10:35 AM, David Fetter wrote:
>
>> It didn't get far, but you may want to take a look at a rejected patch for
>> copy_srf() (set returning function)
>> https://www.postgresql.org/message-id/CADkLM%3DdoeiWQX4AGtDNG4PsWfSXz3ai7kY%3DPZm3sUhsUeev9Bg%40mail.gmail.com
>> https://com
On 1 November 2018 at 12:11, Tomas Vondra wrote:
> I still have trouble imagining what exactly would the function do to
> determine if the optimization can be applied to substr() and similar
> collation-dependent cases.
I guess the function would have to check for a Const offset of 0, and
a colle
On Wed, Oct 31, 2018 at 09:07:43AM -1000, Darafei "Komяpa" Praliaskouski wrote:
> Hi,
>
> I've tried porting some of PostGIS algorithms to utilize multiple cores via
> OpenMP to return faster.
Great!
> Question is, what's the best policy to allocate cores so we can play nice
> with rest of postg
On 10/31/2018 10:07 PM, David Rowley wrote:
> On 1 November 2018 at 05:40, Robert Haas wrote:
>> This kinda reminds me of commit
>> 8f9fe6edce358f7904e0db119416b4d1080a83aa. We needed a way to provide
>> the planner with knowledge about the behavior of specific functions.
>> In that case, the spe
> On Oct 30, 2018, at 9:08 AM, Simon Riggs wrote:
>
> On Tue, 30 Oct 2018 at 07:58, David Rowley
> wrote:
>
> I've started working on something I've ended up calling "Super
> PathKeys". The idea here is to increase the likelihood of a Path with
> PathKeys being used for a purpose that requi
> On Oct 31, 2018, at 5:22 PM, David Rowley
> wrote:
>
> On 1 November 2018 at 04:40, John Naylor wrote:
>> Thanks for doing this. I haven't looked at the rendered output yet,
>> but I have some comments on the content.
>>
>> + Maximum Relation Size
>> + 32 TB
>> + Limited by 2
On 2018-10-30 10:52:54 -0700, Andres Freund wrote:
> On 2018-10-30 11:51:09 +0900, Michael Paquier wrote:
> > On Mon, Oct 29, 2018 at 12:13:04PM -0700, Andres Freund wrote:
> > > I don't think this quite is the problem. ISTM the issue is rather that
> > > StartupReplicationSlots() *needs* to check
On 1 November 2018 at 04:40, John Naylor wrote:
> Thanks for doing this. I haven't looked at the rendered output yet,
> but I have some comments on the content.
>
> + Maximum Relation Size
> + 32 TB
> + Limited by 2^32 pages per relation
>
> I prefer "limited to" or "limited by the
Amit Langote writes:
> Maybe, we don't need to spoil the interface of index_beginscan with the
> new memory context argument like my patch does if the simple following of
> its contract by amendscan would suffice.
Yeah, I'm not enamored of changing the API of index_beginscan for this;
the existin
=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= writes:
> Question is, what's the best policy to allocate cores so we can play nice
> with rest of postgres?
> What I'd like to see is some function that I can call and get a number of
> threads I'm allowed to run, that will also advise rest of
On 1 November 2018 at 05:40, Robert Haas wrote:
> This kinda reminds me of commit
> 8f9fe6edce358f7904e0db119416b4d1080a83aa. We needed a way to provide
> the planner with knowledge about the behavior of specific functions.
> In that case, the specific need was to be able to tell the planner
> th
Hi,
I've tried porting some of PostGIS algorithms to utilize multiple cores via
OpenMP to return faster.
Question is, what's the best policy to allocate cores so we can play nice
with rest of postgres?
What I'd like to see is some function that I can call and get a number of
threads I'm allowed
Robert Haas writes:
> This kinda reminds me of commit
> 8f9fe6edce358f7904e0db119416b4d1080a83aa. We needed a way to provide
> the planner with knowledge about the behavior of specific functions.
> In that case, the specific need was to be able to tell the planner
> that a certain function call c
On Fri, Sep 28, 2018 at 4:20 PM Peter Eisentraut
wrote:
> > - recovery_target (immediate), recovery_target_name, recovery_target_time,
> > recovery_target_xid, recovery_target_lsn are replaced to
> > recovery_target_type and recovery_target_value (was discussed and changed
> > in previous threa
On Tue, Oct 30, 2018 at 8:48 AM Tatsuo Ishii wrote:
> Yes, you need to send params (thus send bind message) anyway.
> Regarding re-parsing, maybe you mixed up parse-analythis with
> planning? Re-parse-analythis can only be avoided if you can reuse
> named (or unnamed) parepared statements.
So giv
On Wed, Aug 22, 2018 at 8:30 AM David Rowley
wrote:
> On 22 August 2018 at 19:08, Amit Langote
> wrote:
> > +#define PartitionTupRoutingGetToParentMap(p, i) \
> > +#define PartitionTupRoutingGetToChildMap(p, i) \
> >
> > If the "Get" could be replaced by "Child" and "Parent", respectively,
> > t
Hi Hackers,
first time writing to the hackers list, so I hope this is the right place to
ask. I recently joined Swarm64 and we are building a postgres extension with
the fdw interface.
I am trying to evaluate sql statements with ExecutorBeing, -Run, -End, -Finish
calls during ExecForeignInsert
On Wed, Oct 31, 2018 at 6:05 AM Hubert Zhang wrote:
> In PG READ UNCOMMITTED is treated as READ COMMITTED
> But I have a requirement to read dirty table. Is there way to detect table
> which is created in other uncommitted transaction?
>
> T1:
> BEGIN;
> create table a(i int);
>
> T2:
> select *
:-( My fault, I just created a new one.
Hmmm... so did I:-) We did it a few minutes apart. I did not find yours
when I first searched, then I proceeded to try to move the previous CF
entry which had been marked as "returned" but this was rejected, so I
recreated the one without checking whe
st 31. 10. 2018 v 7:34 odesílatel Amit Langote <
langote_amit...@lab.ntt.co.jp> napsal:
> On 2018/10/31 15:30, Pavel Stehule wrote:
> > st 31. 10. 2018 v 3:27 odesílatel Amit Langote <
> > langote_amit...@lab.ntt.co.jp> napsal:
> >> +appendPQExpBufferStr(&buf, "\nWHERE c.relkind IN ('p')\n");
On Mon, Oct 29, 2018 at 12:48 PM Andrew Gierth
wrote:
> Then FETCH FIRST N WITH TIES becomes "stop when the expression
> rank() over (order by ...) <= N
> is no longer true" (where the ... is the existing top level order by)
Wouldn't that be wicked expensive compared to something hard-coded
tha
On Mon, Oct 29, 2018 at 6:48 PM Michael Paquier wrote:
> All the backup-related functions doing on-disk activity are marked as
> parallel-restricted:
> =# select proparallel, proname from pg_proc where proname ~ 'backup';
> proparallel | proname
> -+--
> s
On 10/31/2018 12:44 PM, Fabien COELHO wrote:
Hello Andrew,
This patch addresses all these concerns.
Patch v4 applies cleanly, compiles, doc generation ok, global & local
tests ok.
Tiny comments: there is a useless added blank line at the beginning of
the added varlistenry.
I have re
On Tue, Oct 23, 2018 at 9:42 AM John Naylor wrote:
> A case could be made for setting the threshold to 4, since not having
> 3 blocks of FSM in shared buffers exactly makes up for the 3 other
> blocks of heap that are checked when free space runs out.
That doesn't seem like an unreasonable argume
Hello Andrew,
This patch addresses all these concerns.
Patch v4 applies cleanly, compiles, doc generation ok, global & local
tests ok.
Tiny comments: there is a useless added blank line at the beginning of the
added varlistenry.
I have recreated the CF entry and put the patch to ready.
On Wed, Oct 31, 2018 at 9:19 AM Tomas Vondra
wrote:
> I think it can't be made just by adding a couple of columns to pg_proc,
> as explained above. A separate catalog mapping procs to opclasses (and
> maybe collations) may be needed. For cases where it depends on the
> actual parameter values (lik
Hello Amit
Tks a lot, that worked.
Now I have to deal with other concerns when lauching more than 1 worker.
I'll try to advance my tests.
Regards,
Sanyo Moura
Em qua, 31 de out de 2018 às 01:38, Amit Langote <
langote_amit...@lab.ntt.co.jp> escreveu:
> Hi,
>
> On 2018/10/31 3:25, Sanyo Moura wr
On 10/30/18, David Rowley wrote:
> On 26 October 2018 at 11:40, Haribabu Kommi
> wrote:
>> On Fri, Oct 26, 2018 at 9:30 AM David Rowley
>>
>> wrote:
>>>
>>> For a long time, we documented our table size, max columns, max column
>>> width limits, etc. in https://www.postgresql.org/about/ , but th
Hi,
On 2018-10-31 11:13:13 -0400, Andrew Dunstan wrote:
> I agree that just sending a blob of the internal format isn't a great idea.
It's entirely unacceptable afaict. Besides the whole "exposing
internals" issue, it's also at least not endianess safe, depends on the
local alignment requirements
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I dunno, I do not think it's a great idea to expose jsonb's internal
> >> format to the world. We intentionally did not do that when the type
> >> was first defined --- that'
On 10/31/2018 10:21 AM, Tom Lane wrote:
Stephen Frost writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I dunno, I do not think it's a great idea to expose jsonb's internal
format to the world. We intentionally did not do that when the type
was first defined --- that's why its binary I/O form
David Rowley wrote:
> On 31 October 2018 at 13:05, David Rowley
> wrote:
> >>> On 28 October 2018 at 03:49, Julien Rouhaud wrote:
> >> I've registered as a reviewer. I still didn't have a deep look at
> >> the patch yet, but thanks a lot for working on it!
> >
> > Thanks for signing up to re
Hi,
On 2018-10-31 15:32:24 +0100, Daniel Gustafsson wrote:
> Am I right in interpreting the below comment in xlog.c as documenting a new
> mode of operation, so “Not” should actually be “Note”? Or am I just not able
> to English today?
No, you're right. Fixed!
Greetings,
Andres Freund
Am I right in interpreting the below comment in xlog.c as documenting a new
mode of operation, so “Not” should actually be “Note”? Or am I just not able
to English today?
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index 62fc418893..246869bba2 100644
--- a/
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I dunno, I do not think it's a great idea to expose jsonb's internal
>> format to the world. We intentionally did not do that when the type
>> was first defined --- that's why its binary I/O format isn't already
>> like this --- an
On 10/13/2018 10:07 AM, Fabien COELHO wrote:
Hello Andrew,
A question: would it makes sense to have a symmetrical
--include-database=PATTERN option as well?
I don't think so. If you only want a few databases, just use pg_dump.
The premise of pg_dumpall is that you want all of them and thi
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Kevin Van writes:
> > This patch adds a new function that allows callers to receive binary jsonb.
> > This change was proposed in the discussion here:
> > https://www.postgresql.org/message-id/CAOsiKEL7%2BKkV0C_hAJWxqwTg%2BPYVfiGPQ0yjFww7ECtqwBj
On 10/31/2018 04:32 AM, David Rowley wrote:
On 31 October 2018 at 14:23, Tomas Vondra wrote:
The other thing likely affecting this is locale / collation. Probably
not for date_trunc, but certainly for things like substr()/trim(),
mentioned by Simon upthread.
In some languages the rules are pre
On Wed, Oct 31, 2018 at 1:42 PM John Naylor wrote:
>
> Upthread I wrote:
>
> > -A possible TODO item is to teach pg_upgrade not to link FSMs for
> > small heaps. I haven't look into the feasibility of that, however.
>
> This turned out to be relatively light weight (0002 attached). I had
> to add
Hi
> OK, so the problem is COPY.
>
> Which means we have an issue with restore. We need to be able to pg_dump a
> table with generated columns, then restore it afterwards. More generally, we
> need to be able to handle data that has already been generated - the
> "generate" idea should apply to
On Wed, 31 Oct 2018 at 08:29, Erik Rijkers wrote:
> On 2018-10-31 09:15, Simon Riggs wrote:
> > On Wed, 31 Oct 2018 at 07:58, Erikjan Rijkers wrote:
> >
> >
> >> I have also noticed that logical replication isn't possible on tables
> >> with a generated column. That's a shame but I suppsoe that
* Andreas 'ads' Scherbaum (a...@pgug.de) wrote:
> On 30.10.18 11:49, Andrew Dunstan wrote:
> >On 10/30/2018 06:14 AM, Andreas 'ads' Scherbaum wrote:
> >>On 30.10.18 04:11, Michael Paquier wrote:
> >>>FWIW, I think that people depend too much on github and what github
> >>>thinks projects should do
Kevin Van writes:
> This patch adds a new function that allows callers to receive binary jsonb.
> This change was proposed in the discussion here:
> https://www.postgresql.org/message-id/CAOsiKEL7%2BKkV0C_hAJWxqwTg%2BPYVfiGPQ0yjFww7ECtqwBjb%2BQ%40mail.gmail.com
> and the primary motivation is to r
This patch adds a new function that allows callers to receive binary jsonb.
This change was proposed in the discussion here:
https://www.postgresql.org/message-id/CAOsiKEL7%2BKkV0C_hAJWxqwTg%2BPYVfiGPQ0yjFww7ECtqwBjb%2BQ%40mail.gmail.com
and the primary motivation is to reduce database load by skip
> On Mon, 29 Oct 2018 at 05:56, Haribabu Kommi wrote:
>
>> This problem couldn't be reproduced on the master branch, so I've tried to
>> investigate it. It comes from nodeModifyTable.c:1267, when we've got
>> HeapTupleInvisible as a result, and this value in turn comes from
>> table_lock_tuple. Ev
Hi all,
In PG READ UNCOMMITTED is treated as READ COMMITTED
But I have a requirement to read dirty table. Is there way to detect table
which is created in other uncommitted transaction?
T1:
BEGIN;
create table a(i int);
T2:
select * from pg_class where relname='a';
could return table a?
--
Than
В письме от 12 сентября 2018 21:40:49 пользователь Nikolay Shaplov написал:
> > As you mentioned in previous mail, you prefer to keep enum and
> > relopt_enum_element_definition array in the same .h file. I'm not sure,
> > but I think it is done to keep everything related to enum in one place
> > t
st 31. 10. 2018 v 8:55 odesílatel Michael Paquier
napsal:
> On Wed, Oct 31, 2018 at 08:38:27AM +0100, Pavel Stehule wrote:
> > ok. Unfortunatelly it is not mentioned in release notes - in not
> compatible
> > changes.
> >
> > This change can hit lot of users. It is small nonsense, but lot of peop
Hi Andrei,
First, I inform you that I may not contact for the following period:
From November 1st to November 19th
Second, I noticed my misunderstanding in previous mail.
> > Nevertheless, it is necessary to take into account that the option
> > TCP_USER_TIMEOUT is supported by Linux kernel start
On 2018-10-31 09:15, Simon Riggs wrote:
On Wed, 31 Oct 2018 at 07:58, Erikjan Rijkers wrote:
I have also noticed that logical replication isn't possible on tables
with a generated column. That's a shame but I suppsoe that is as
expected.
Couldn't see anything like that in the patch. Presu
On Wed, 31 Oct 2018 at 07:58, Erikjan Rijkers wrote:
> I have also noticed that logical replication isn't possible on tables
> with a generated column. That's a shame but I suppsoe that is as
> expected.
>
Couldn't see anything like that in the patch. Presumably unintended
consequence. The gen
Upthread I wrote:
> -A possible TODO item is to teach pg_upgrade not to link FSMs for
> small heaps. I haven't look into the feasibility of that, however.
This turned out to be relatively light weight (0002 attached). I had
to add relkind to the RelInfo struct and save the size of each heap as
it
On Wed, Oct 31, 2018 at 08:41:45AM +0100, Pavel Stehule wrote:
> I am not sure - I remember one private test that we did on our patches, and
> this tests fails sometimes on 32bits. So I afraid about stability.
That could be possible as well. I think that you are right to be afraid
of such things,
On 2018-10-30 16:14, Sergei Kornilov wrote:
Hi
I applied this patch on top 2fe42baf7c1ad96b5f9eb898161e258315298351
commit and found a bug while adding STORED column:
postgres=# create table test(i int);
CREATE TABLE
postgres=# insert into test values (1),(2);
INSERT 0 2
postgres=# alter table
On Wed, Oct 31, 2018 at 08:38:27AM +0100, Pavel Stehule wrote:
> ok. Unfortunatelly it is not mentioned in release notes - in not compatible
> changes.
>
> This change can hit lot of users. It is small nonsense, but lot of people
> use it.
Please just look at the order of the words in the command
On Tue, Oct 30, 2018 at 11:47 PM Surafel Temesgen wrote:
>
>
> Hi,
> Thank you for looking at it .
> On Sun, Oct 28, 2018 at 7:19 PM Tomas Vondra
> wrote:
>>
>>
>> 1) I think this deserves at least some regression tests. Plenty of tests
>> already use COPY, but there's no coverage for the new pi
On Wed, Oct 31, 2018 at 08:19:35AM +0100, Pavel Stehule wrote:
> I have report of one customer. Some scripts stopped on 11 because VACUUM
> ANALYZE VERBOSE doesn't work now.
>
> postgres=# vacuum analyze verbose;
> ERROR: syntax error at or near "verbose"
> LINE 1: vacuum analyze verbose;
>
st 31. 10. 2018 v 8:38 odesílatel Michael Paquier
napsal:
> On Wed, Oct 31, 2018 at 03:34:02PM +0900, Amit Langote wrote:
> > On 2018/10/31 15:30, Pavel Stehule wrote:
> >> I am not sure. Has not sense run this test over empty database, and some
> >> bigger database can increase running.
> >>
> >
st 31. 10. 2018 v 8:34 odesílatel Sergei Kornilov napsal:
> Hi
>
> At least this is documented behavior:
> > When the option list is surrounded by parentheses, the options can be
> written in any order. Without parentheses, options must be specified in
> exactly the order shown above.
> https://w
On Wed, Oct 31, 2018 at 03:34:02PM +0900, Amit Langote wrote:
> On 2018/10/31 15:30, Pavel Stehule wrote:
>> I am not sure. Has not sense run this test over empty database, and some
>> bigger database can increase running.
>>
>> More the size can be platform depend.
>
> Okay, sure.
Well, that wo
Hi
At least this is documented behavior:
> When the option list is surrounded by parentheses, the options can be written
> in any order. Without parentheses, options must be specified in exactly the
> order shown above.
https://www.postgresql.org/docs/current/static/sql-vacuum.html
Previously
On Mon, Oct 29, 2018 at 2:20 AM Tomas Vondra
wrote:
>
> Hi,
>
> On 10/02/2018 04:33 AM, Michael Paquier wrote:
> > On Sat, Sep 08, 2018 at 02:21:27AM +0300, Nikita Glukhov wrote:
> >> Attached 18th version of the patches rebased onto the current master.
> >
> > Nikita, this version fails to apply,
On Tue, Oct 30, 2018 at 09:35:18AM +0100, Peter Eisentraut wrote:
> Attached is a new version of this patch.
Thanks Peter for sending a new patch. I am still assigned as a
reviewer, and still plan to look at it in more details.
> It supports both computed-on-write and computed-on-read variants,
Hi
I have report of one customer. Some scripts stopped on 11 because VACUUM
ANALYZE VERBOSE doesn't work now.
postgres=# vacuum analyze verbose;
ERROR: syntax error at or near "verbose"
LINE 1: vacuum analyze verbose;
^
vacuum verbose analyze is working.
Regards
Pavel
92 matches
Mail list logo
