On Sat, Sep 26, 2020 at 1:51 PM Julien Rouhaud wrote:
> On Sat, Sep 26, 2020 at 8:17 AM Andy Fan wrote:
> >
> > As for the testing with cache considered, I found how to estimate cache
> hit
> > ratio is hard or how to control a hit ratio to test is hard. Recently I
> am thinking
> > a method tha
On Fri, Sep 25, 2020 at 11:06 PM Fujii Masao
wrote:
>
> On 2020/09/25 12:06, Masahiro Ikeda wrote:
> > On 2020-09-18 11:11, Kyotaro Horiguchi wrote:
> >> At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda
> >> wrote in
> >>> Thanks. I confirmed that it causes HOT pruning or killing of
> >>> dead
On Thu, Aug 20, 2020 at 4:36 PM Kyotaro Horiguchi
wrote:
> This is rebased version.
Thanks for the rebased version!
> Come to think of "complex", ExecAsync stuff in this patch might be
> too-much for a short-term solution until executor overhaul, if it
> comes shortly. (the patch of mine here as
On Wed, Sep 23, 2020 at 1:09 PM Keisuke Kuroda
wrote:
>
> Hi hackers,
>
> I found a problem in logical replication.
> It seems to have the same cause as the following problem.
>
> Creating many tables gets logical replication stuck
>
> https://www.postgresql.org/message-id/flat/20f3de7675f831
Hi,
In all the static analysis tools I’ve used, there are literally *hundreds*
of alerts about a one suspect cast:
64 bits sizet_t -> 32 bits int -> 64 bits size_t
-#define VARHDRSZ ((int32) sizeof(int32))
+#define VARHDRSZ (sizeof(int32))
Is there any special reason for not simplifying this and
On Tue, 1 Sep 2020 at 05:22, Tom Lane wrote:
>
> I wrote:
> > One inefficiency I see that we could probably get rid of is
> > where make_subplan() is doing
> > /* Now we can check if it'll fit in hash_mem */
> > /* XXX can we check this at the Path stage? */
>
> I went ahea
On Wed, Sep 23, 2020 at 2:21 PM Greg Nancarrow wrote:
>
> > - When INSERTs are made parallel, currently the reported row-count in
> > the "INSERT 0 " status only reflects the rows that the
> > leader has processed (not the workers) - so it is obviously less than
> > the actual number of rows inser
I wrote:
> BTW, I think it would be worth splitting this into separate server-side
> and libpq patches. It looked to me like the server side is pretty
> nearly committable, modulo bikeshedding about the new GUC name.
Actually ... I looked that over again and got a bit more queasy about
all the ne
Hi,
With sqlsmith I found a query that gives this error:
ERROR: ORDER/GROUP BY expression not found in targetlist
I noted the query (sql query below, sorry it uses custom tables i
couldn't replicate with regression tables) because it doesn't include
an ORDER/GROUP BY clause.
--- 0
select d
On Thu, Sep 24, 2020 at 05:11:03PM +0900, Michael Paquier wrote:
> start. So, the goal of the patch, as I would define it, is to give a
> way to CLUSTER to work on a partitioned table using a given
> partitioned index. Hence, we would perform CLUSTER automatically from
> the top-most parent for a
Thanks for reviewing!
David Rowley writes:
> 1. I think we should be moving away from using linitial() and second()
> when we know there are two items in the list. Using list_nth() has
> less overhead.
Uh, really? And if it's true, why would we change all the call sites
rather than improving th
Ranier Vilela writes:
> In all the static analysis tools I’ve used, there are literally *hundreds*
> of alerts about a one suspect cast:
> 64 bits sizet_t -> 32 bits int -> 64 bits size_t
> -#define VARHDRSZ ((int32) sizeof(int32))
> +#define VARHDRSZ (sizeof(int32))
Given that the compiler can
On Fri, Jun 05, 2020 at 05:16:43PM +0200, Antonin Houska wrote:
> Antonin Houska wrote:
>
> > In general, the checks are significantly faster if there are many rows to
> > process, and a bit slower when we only need to check a single row.
>
> Attached is a new version that uses the existing simp
13 matches
Mail list logo
