On 01/05/2020 05:20, James Coleman wrote:
On Tue, Apr 28, 2020 at 8:25 AM Tomas Vondra
wrote:
...
Any particular reasons to pick dynahash over simplehash? ISTM we're
using simplehash elsewhere in the executor (grouping, tidbitmap, ...),
while there are not many places using dynahash for simple
On Tue, Aug 18, 2020 at 10:27:06PM -0500, Justin Pryzby wrote:
> On Fri, Aug 07, 2020 at 02:30:01PM +0200, Pierre Giraud wrote:
> > Hi all,
> >
> > As far as I understand, in the upcoming version 13, information about
> > buffers used during planning is now available in the explain plan.
> >
> >
On Tue, 18 Aug 2020 at 13:06, Amit Kapila wrote:
>
> On Mon, Aug 17, 2020 at 11:38 AM Masahiko Sawada
> wrote:
> >
> > On Sat, 15 Aug 2020 at 12:19, Amit Kapila wrote:
> > >
> > > The reason why I have not included heap_page_prune related change in
> > > the patch is that I don't want to sprinkl
On Wed, Aug 19, 2020 at 10:11 AM Amit Kapila wrote:
>
> On Mon, Aug 17, 2020 at 6:29 PM Dilip Kumar wrote:
> >
> >
> > In last patch v49-0001, there is one issue, Basically, I have called
> > BufFileFlush in all the cases. But, ideally, we can not call this if
> > the underlying files are delet
On Wed, Aug 19, 2020 at 12:20 PM Amit Kapila wrote:
>
> On Wed, Aug 19, 2020 at 10:10 AM Amit Kapila wrote:
> >
> > On Mon, Aug 17, 2020 at 6:29 PM Dilip Kumar wrote:
> > >
> > >
> > > In last patch v49-0001, there is one issue, Basically, I have called
> > > BufFileFlush in all the cases. But
‐‐‐ Original Message ‐‐‐
On Friday, 7 August 2020 09:02, Asim Praveen wrote:
> > On 05-Aug-2020, at 7:01 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
> > On 2020-Aug-05, Asim Praveen wrote:
> >
> > > Please find attached a StringInfo based solution to this problem. It
> > > uses f
On 2020-08-19 15:48, Fujii Masao wrote:
On 2020/08/19 9:43, torikoshia wrote:
On 2020-08-18 22:54, Fujii Masao wrote:
On 2020/08/18 18:41, torikoshia wrote:
On 2020-08-17 21:19, Fujii Masao wrote:
On 2020/08/17 21:14, Fujii Masao wrote:
On 2020-08-07 16:38, Kasahara Tatsuhito wrote:
The foll
On Wed, 19 Aug 2020 at 19:22, Julien Rouhaud wrote:
> Hearing no objection, here's a patch to change the output as suggested by
> Pierre:
>
> =# explain (analyze, buffers) select * from pg_class;
>QUERY PLAN
>
On Wed, Aug 19, 2020 at 08:49:48PM +1200, David Rowley wrote:
> On Wed, 19 Aug 2020 at 19:22, Julien Rouhaud wrote:
> > Hearing no objection, here's a patch to change the output as suggested by
> > Pierre:
> >
> > =# explain (analyze, buffers) select * from pg_class;
> >
On 2020/08/19 17:40, torikoshia wrote:
On 2020-08-19 15:48, Fujii Masao wrote:
On 2020/08/19 9:43, torikoshia wrote:
On 2020-08-18 22:54, Fujii Masao wrote:
On 2020/08/18 18:41, torikoshia wrote:
On 2020-08-17 21:19, Fujii Masao wrote:
On 2020/08/17 21:14, Fujii Masao wrote:
On 2020-08-0
On Wed, 19 Aug 2020 at 15:09, Ashutosh Sharma wrote:
>
> On Wed, Aug 19, 2020 at 9:27 AM Masahiko Sawada
> wrote:
> >
> > On Mon, 17 Aug 2020 at 15:05, Ashutosh Sharma wrote:
> > >
> > > > pg_force_freeze() can revival a tuple that is already deleted but not
> > > > vacuumed yet. Therefore, the
On Wed, 19 Aug 2020 at 21:05, Julien Rouhaud wrote:
>
> On Wed, Aug 19, 2020 at 08:49:48PM +1200, David Rowley wrote:
> > However, I'm not quite sure how we should handle if someone does:
> > EXPLAIN (BUFFERS on, SUMMARY off). Without the summary, there's no
> > place to print the buffers, which s
On Wed, 19 Aug 2020 at 22:39, David Rowley wrote:
> so, maybe we can just error if analyze == off AND buffers == on AND
> summary == off. We likely should pay attention to analyze there as it
> seems perfectly fine to EXPLAIN (ANALYZE, BUFFERS, SUMMARY off). We
> quite often do SUMMARY off for th
On Tue, Aug 18, 2020 at 6:53 AM Peter Geoghegan wrote:
> I definitely think that we should have something like this, though.
> It's a relatively easy win. There are plenty of workloads that spend
> lots of time on pruning.
Alright then, here's an attempt to flesh the idea out a bit more, and
repl
On Wed, Aug 19, 2020 at 3:55 PM Masahiko Sawada
wrote:
>
> On Wed, 19 Aug 2020 at 15:09, Ashutosh Sharma wrote:
> >
> > On Wed, Aug 19, 2020 at 9:27 AM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, 17 Aug 2020 at 15:05, Ashutosh Sharma
> > > wrote:
> > > >
> > > > > pg_force_freeze() can revi
Hi,
I couldn't test the patch as it does not apply cleanly on master.
Please find below some review comments:
1. Would it better to throw a warning at the time of dropping the
REPLICA IDENTITY
index that it would also drop the REPLICA IDENTITY of the parent table?
2. CCI is used after cal
On 2020/08/12 15:32, Masahiko Sawada wrote:
On Wed, 12 Aug 2020 at 14:06, Asim Praveen wrote:
On 11-Aug-2020, at 8:57 PM, Robert Haas wrote:
I think this gets to the root of the issue. If we check the flag
without a lock, we might see a slightly stale value. But, considering
that there
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Overall, the patch works fine. However, I have a few observations:
(1) C
Hi,
I started to hack on making pg_rewind crash-safe (see [1]), but I
quickly got side-tracked into refactoring and tidying up up the code in
general. I ended up with this series of patches:
The first four patches are just refactoring that make the code and the
logic more readable. Tom Lane
On 18.08.2020 02:54, Alvaro Herrera wrote:
On 2020-Aug-14, Ibrar Ahmed wrote:
The table used for the test contains three columns (integer, text,
varchar).
The total number of rows is 1000 in total.
Unpatched (Master: 92c12e46d5f1e25fc85608a6d6a19b8f5ea02600)
COPY: 9069.432 ms vacuum; 2567.
> On 12-Aug-2020, at 12:02 PM, Masahiko Sawada
> wrote:
>
> On Wed, 12 Aug 2020 at 14:06, Asim Praveen wrote:
>>
>>
>>
>>> On 11-Aug-2020, at 8:57 PM, Robert Haas wrote:
>>>
>>> I think this gets to the root of the issue. If we check the flag
>>> without a lock, we might see a slightly s
On Wed, Aug 19, 2020 at 05:33:36PM +0530, Rahila Syed wrote:
> I couldn't test the patch as it does not apply cleanly on master.
The CF bot is green, and I can apply v2 cleanly FWIW:
http://commitfest.cputube.org/michael-paquier.html
> Please find below some review comments:
>
> 1. Would it bett
Thanks Alvaro for review.
On Wed, Aug 19, 2020 at 3:21 AM Alvaro Herrera wrote:
>
> I didn't like that you're documenting the message format in the new
> function:
>
> > xl_logical_message *xlrec = (xl_logical_message *) rec;
> > + /*
> > + * Per LogLogicalM
On Tue, Aug 18, 2020 at 07:34:00PM -0700, Andres Freund wrote:
> It seems like the buildfarm ought to configure the started server with a
> bunch of prepared transactions, in that case? At least going forward?
Agreed. Testing with max_prepared_transactions > 0 has much more
value than not, for su
On 8/18/20 9:22 PM, Andres Freund wrote:
> Hi,
>
> This thread started on committers, at
> https://www.postgresql.org/message-id/20200818234532.uiafo5br5lo6zhya%40alap3.anarazel.de
>
> In it I wanted to add a isolation test around prepared transactions:
>
> On 2020-08-18 16:45:32 -0700, Andres Fr
On Wed, Aug 19, 2020 at 06:12:02PM +0900, Fujii Masao wrote:
> On 2020/08/19 17:40, torikoshia wrote:
>> Yes, I didn't add regression tests because of the unstability of the output.
>> I thought it would be OK since other views like pg_stat_slru and
>> pg_shmem_allocations
>> didn't have tests for
On Tue, Jul 28, 2020 at 10:55:04AM +0200, Julien Rouhaud wrote:
> On Tue, Jul 28, 2020 at 10:07 AM torikoshia
> wrote:
> >
> > Thanks for updating!
> > I tested the patch setting log_statement = 'all', but %Q in
> > log_line_prefix
> > was always 0 even when pg_stat_statements.queryid and
> > pg_
Hadn't been paying attention to this thread up till now, but ...
Michael Paquier writes:
> By the way, I was looking at the code that has been committed, and I
> think that it is awkward to have a SQL function in mcxt.c, which is a
> rather low-level interface. I think that this new code should
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I have performed testing of the patch with row comparison partiti
On 2020/08/19 19:39, David Rowley wrote:
On Wed, 19 Aug 2020 at 21:05, Julien Rouhaud wrote:
On Wed, Aug 19, 2020 at 08:49:48PM +1200, David Rowley wrote:
However, I'm not quite sure how we should handle if someone does:
EXPLAIN (BUFFERS on, SUMMARY off). Without the summary, there's no
pla
Thomas Munro writes:
> On Tue, Jul 28, 2020 at 3:27 PM Tom Lane wrote:
>> Anyway, I guess the interesting question for us is how long it
>> will take for this fix to propagate into real-world systems.
>> I don't have much of a clue about the Linux kernel workflow,
>> anybody want to venture a gue
As a note I tried to use the deb repo today:
https://www.postgresql.org/download/linux/debian/
with an old box on Wheezy.
It only seems to have binaries up to postgres 10.
Might be nice to make a note on the web page so people realize some
distro's aren't supported fully instead of (if they're l
Hi hackers,
More than month ago I have sent bug report to pgsql-bugs:
https://www.postgresql.org/message-id/flat/5d335911-fb25-60cd-4aa7-a5bd0954aea0%40postgrespro.ru
with the proposed patch but have not received any response.
I wonder if there is some other way to fix this issue and does some
On Wed, Aug 19, 2020 at 7:04 PM Roger Pack wrote:
> As a note I tried to use the deb repo today:
>
> https://www.postgresql.org/download/linux/debian/
>
> with an old box on Wheezy.
> It only seems to have binaries up to postgres 10.
>
> Might be nice to make a note on the web page so people real
On 2020-Aug-19, Amit Langote wrote:
Hello
> On Thu, Aug 6, 2020 at 4:25 PM kato-...@fujitsu.com
> wrote:
> > On Wednesday, August 5, 2020 9:43 AM I wrote:
> > > I'll report the result before the end of August .
> >
> > I test v2-0001-build-partdesc-memcxt.patch at 9a9db08ae4 and it is ok.
>
> I
On 2020-Aug-11, James Coleman wrote:
> In [3] I'd brought up that a function index can do arbitrary
> operations (including, terribly, a query of another table), and Andres
> (in [4]) noted that:
>
> > Well, even if we consider this an actual problem, we could still use
> > PROC_IN_CIC for non-ex
Hi
st 19. 8. 2020 v 19:22 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
> Hi hackers,
>
> More than month ago I have sent bug report to pgsql-bugs:
>
>
> https://www.postgresql.org/message-id/flat/5d335911-fb25-60cd-4aa7-a5bd0954aea0%40postgrespro.ru
>
> with the proposed pa
On 19.08.2020 21:50, Pavel Stehule wrote:
Hi
st 19. 8. 2020 v 19:22 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
Hi hackers,
More than month ago I have sent bug report to pgsql-bugs:
https://www.postgresql.org/message-id/flat/5d335911-fb25-60cd-4a
st 19. 8. 2020 v 20:59 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 19.08.2020 21:50, Pavel Stehule wrote:
>
> Hi
>
> st 19. 8. 2020 v 19:22 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>> Hi hackers,
>>
>> More than month ago I have sent
Hello
The REINDEX CONCURRENTLY documentation states that if a transient index
used lingers, the fix is to drop the invalid index and perform RC again;
and that this is to be done for "ccnew" indexes and also for "ccold"
indexes:
The recommended recovery method in such cases is to drop the inv
On Wed, 19 Aug 2020 at 16:23, Tom Lane wrote:
>
> David Rowley writes:
> > I don't object to making the change. I just object to making it only
> > to put it back again later when someone else speaks up that they'd
> > prefer to keep nodes modular and not overload them in obscure ways.
>
> > So o
On Wed, 19 Aug 2020 at 16:18, Pavel Stehule wrote:
>
>
>
> st 19. 8. 2020 v 5:48 odesílatel David Rowley napsal:
>> Current method:
>>
>> regression=# explain (analyze, costs off, timing off, summary off)
>> select twenty, (select count(*) from tenk1 t2 where t1.twenty =
>> t2.twenty) from tenk1
Hi,
On 2020-08-19 11:01:37 -0400, Tom Lane wrote:
> Hadn't been paying attention to this thread up till now, but ...
>
> Michael Paquier writes:
> > By the way, I was looking at the code that has been committed, and I
> > think that it is awkward to have a SQL function in mcxt.c, which is a
> >
On 2020-Aug-19, David Rowley wrote:
> Andres' suggestion:
>
> regression=# explain (analyze, costs off, timing off, summary off)
> select count(*) from tenk1 t1 inner join tenk1 t2 on
> t1.twenty=t2.unique1;
> QUERY PLAN
>
On Wed, Aug 19, 2020 at 11:41 PM Thomas Munro wrote:
> On Tue, Aug 18, 2020 at 6:53 AM Peter Geoghegan wrote:
> > I definitely think that we should have something like this, though.
> > It's a relatively easy win. There are plenty of workloads that spend
> > lots of time on pruning.
>
> Alright t
On Thu, 20 Aug 2020 at 03:31, Fujii Masao wrote:
>
>
>
> On 2020/08/19 19:39, David Rowley wrote:
> > On Wed, 19 Aug 2020 at 21:05, Julien Rouhaud wrote:
> >>
> >> On Wed, Aug 19, 2020 at 08:49:48PM +1200, David Rowley wrote:
> >>> However, I'm not quite sure how we should handle if someone does:
On Thu, 20 Aug 2020 at 10:58, Alvaro Herrera wrote:
> On the performance aspect, I wonder what the overhead is, particularly
> considering Tom's point of making these nodes more expensive for cases
> with no caching.
It's likely small. I've not written any code but only thought about it
and I thi
Hello.
Apologies for the delay.
> > When the server crash occurs during data loading of COPY UNLOGGED,
> > it's a must to keep index consistent of course.
> > I'm thinking that to rebuild the indexes on the target table would work.
> >
> > In my opinion, UNLOGGED clause must be designed to guarant
Andres Freund writes:
> On 2020-08-19 11:01:37 -0400, Tom Lane wrote:
>> I agree with that, but I think this patch has a bigger problem:
>> why bother at all? It seems like a waste of code space and future
>> maintenance effort, because there is no use-case.
> I don't agree with this at all. I t
Hi,
On 2020-08-19 21:29:06 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-08-19 11:01:37 -0400, Tom Lane wrote:
> >> I agree with that, but I think this patch has a bigger problem:
> >> why bother at all? It seems like a waste of code space and future
> >> maintenance effort, because
Hi,
On Thu, Aug 20, 2020 at 3:06 AM Alvaro Herrera wrote:
> On 2020-Aug-19, Amit Langote wrote:
> > On Thu, Aug 6, 2020 at 4:25 PM kato-...@fujitsu.com
> > wrote:
> > > On Wednesday, August 5, 2020 9:43 AM I wrote:
> > > > I'll report the result before the end of August .
> > >
> > > I test v2-0
On 2020/08/20 0:01, Tom Lane wrote:
Hadn't been paying attention to this thread up till now, but ...
Michael Paquier writes:
By the way, I was looking at the code that has been committed, and I
think that it is awkward to have a SQL function in mcxt.c, which is a
rather low-level interface.
On 2020/08/20 10:43, Andres Freund wrote:
Hi,
On 2020-08-19 21:29:06 -0400, Tom Lane wrote:
Andres Freund writes:
On 2020-08-19 11:01:37 -0400, Tom Lane wrote:
I agree with that, but I think this patch has a bigger problem:
why bother at all? It seems like a waste of code space and futur
At Wed, 19 Aug 2020 13:20:46 +, Asim Praveen wrote in
>
>
> > On 12-Aug-2020, at 12:02 PM, Masahiko Sawada
> > wrote:
> >
> > On Wed, 12 Aug 2020 at 14:06, Asim Praveen wrote:
> >>
> >>
> >>
> >>> On 11-Aug-2020, at 8:57 PM, Robert Haas wrote:
> >>>
> >>> I think this gets to the r
Hello
I have a publisher instance, cpu 32 core, ram 64GB, with SSD and installed
PostgreSQL 10 on it. I want to use logical replication with it , I
create publication on it, add about 20 tables in the pub, each tables will
have about 1 million line data,.
I wonder how many subscriber instance
On 2020/08/20 0:01, Tom Lane wrote:
> The only situation I could imagine where this would have any use is
> where there is long-term (cross-query) bloat in, say, CacheMemoryContext
Yeah, in cases where a very large number of sessions are connected to
the DB for very long periods of time, the memory
At Wed, 19 Aug 2020 21:41:03 +0900, Fujii Masao
wrote in
>
>
> On 2020/08/12 15:32, Masahiko Sawada wrote:
> > On Wed, 12 Aug 2020 at 14:06, Asim Praveen wrote:
> >>
> >>
> >>
> >>> On 11-Aug-2020, at 8:57 PM, Robert Haas wrote:
> >>>
> >>> I think this gets to the root of the issue. If we c
čt 20. 8. 2020 v 0:04 odesílatel David Rowley napsal:
> On Wed, 19 Aug 2020 at 16:18, Pavel Stehule
> wrote:
> >
> >
> >
> > st 19. 8. 2020 v 5:48 odesílatel David Rowley
> napsal:
> >> Current method:
> >>
> >> regression=# explain (analyze, costs off, timing off, summary off)
> >> select twen
On Thu, 20 Aug 2020 at 03:31, Fujii Masao wrote:
> With the patch, for example, whatever "summary" settng is, "buffers on"
> displays the planner's buffer usage if it happens.
I forgot to mention earlier, you'll also need to remove the part in
the docs that mentions BUFFERS requires ANALYZE.
Dav
On Thu, Jul 02, 2020 at 11:14:48AM +0900, Kyotaro Horiguchi wrote:
> As the result of a discussion with Fujita-san off-list, I'm going to
> hold off development until he decides whether mine or Thomas' is
> better.
The latest patch doesn't apply so I set as WoA.
https://commitfest.postgresql.org/2
On Mon, Aug 17, 2020 at 11:10:05PM +0530, vignesh C wrote:
> On Sat, Aug 1, 2020 at 8:12 AM vignesh C wrote:
> > > >
> > > > +-- access method column should not be displayed for sequences
> > > > +\ds+
> > > >
> > > > - List of relations
> > > >
> > > >
> > > > - Schema
On Wed, Aug 19, 2020 at 12:54 PM Masahiko Sawada
wrote:
>
> On Tue, 18 Aug 2020 at 13:06, Amit Kapila wrote:
> >
> >
> > I don't think we need to expose LVRelStats. We can just pass the
> > address of vacrelstats->offset_num to achieve what we want. I have
> > tried that and it works, see the
> >
On Wed, Aug 19, 2020 at 05:13:12PM -0400, Alvaro Herrera wrote:
> In other words I propose to reword this paragraph as follows:
>
>If the transient index created during the concurrent operation is
>suffixed ccnew, the recommended recovery method
>is to drop the invalid index using DROP
On Wed, 19 Aug 2020 at 20:45, Ashutosh Sharma wrote:
>
> On Wed, Aug 19, 2020 at 3:55 PM Masahiko Sawada
> wrote:
> >
> > On Wed, 19 Aug 2020 at 15:09, Ashutosh Sharma wrote:
> > >
> > > On Wed, Aug 19, 2020 at 9:27 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Mon, 17 Aug 2020 at 15:05, A
On Wed, Aug 19, 2020 at 02:16:46PM -0400, Alvaro Herrera wrote:
> I did not set the flag in REINDEX CONCURRENTLY, but as I understand it
> can be done too, since in essence it's the same thing as a CIC from a
> snapshot management point of view.
Yes, I see no problems for REINDEX CONCURRENTLY as w
On Thu, Aug 20, 2020 at 11:04 AM Masahiko Sawada
wrote:
>
> On Wed, 19 Aug 2020 at 20:45, Ashutosh Sharma wrote:
> >
> > On Wed, Aug 19, 2020 at 3:55 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, 19 Aug 2020 at 15:09, Ashutosh Sharma
> > > wrote:
> > > >
> > > > On Wed, Aug 19, 2020 at 9:2
At Thu, 20 Aug 2020 00:18:52 +, "osumi.takami...@fujitsu.com"
wrote in
> Hello.
>
> Apologies for the delay.
> > > When the server crash occurs during data loading of COPY UNLOGGED,
> > > it's a must to keep index consistent of course.
> > > I'm thinking that to rebuild the indexes on the t
On Thu, 20 Aug 2020 at 14:01, Amit Kapila wrote:
>
> On Wed, Aug 19, 2020 at 12:54 PM Masahiko Sawada
> wrote:
> >
> > On Tue, 18 Aug 2020 at 13:06, Amit Kapila wrote:
> > >
> > >
> > > I don't think we need to expose LVRelStats. We can just pass the
> > > address of vacrelstats->offset_num to a
68 matches
Mail list logo
