On Thu, Apr 19, 2018 at 9:42 AM, Teodor Sigaev wrote:
> But some later, in _bt_unlink_halfdead_page() we check ItemPointer high key
> with ItemPointerIsValid macro - and it returns false, because offset is
> actually InvalidOffsetNumber - i.e. 0 which was set by BTreeTupleSetNAtts.
> And some wron
> "Andrew" == Andrew Gierth writes:
Andrew> There is still some overhead in the check, of course; I will
Andrew> see about doing some benchmarks.
Preliminary result suggests that the user-CPU cost of vacuum full
increases by ~16% when the entire table is recently-dead rows (with a
toasted
> "Andres" == Andres Freund writes:
Andres> Please wait for a bit. This isn't a trivial change, and I would
Andres> like to wrap my head around it.
Sure.
Andres> At the very least this seems like it could cause extreme
Andres> slowdowns for large tables that have the right update/delete
Just for the record, I tried the test case with ZFS on Ubuntu 17.10 host
with ZFS on Linux 0.6.5.11.
ZFS does not swallow the fsync error, but the system does not handle the
error nicely: the test case program hangs on fsync, the load jumps up
and there's a bunch of z_wr_iss and z_null_int kernel
Hi,
On 2018-04-21 14:16:27 +0100, Andrew Gierth wrote:
> > "Amit" == Amit Kapila writes:
>
> Amit> (c) Change the logic during rewrite such that it can detect this
> Amit> situation and skip copying the tuple in the main table,
>
> So I dug into this one and it looks to me like the best a
Amit Langote writes:
> I think if this bug/open item can be resolved by adopting the minimal
> patch, then we should use it for that. Maybe, we can discuss the rest of
> the changes independently. If they make things better overall, we should
> definitely try to adopt them.
Yeah. While I think
Amit Langote writes:
> [ v8-0001-Allow-generalized-expression-syntax-for-partition.patch ]
I find what you did to a_expr here to be pretty horrid.
I think what you should do is lose the partbound_datum and
PartitionRangeDatum productions altogether, replacing those with just
a_expr, as in the at
On 04/20/2018 07:55 PM, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (and...@anarazel.de) wrote:
>> It's common that half the buildfarm has reported back before a single
>> windows buildfarm animal reports. And if they report a failure one often
>> has to wait for hours for the next run.
Gourav Kumar writes:
> I have modified the PostgreSQL source code for my project implementation.
> In the modified code, I am calling query_planner function several times
> while I am inside the grouping planner function.
> As the number of executions increase I have noticed memory leaks in the
>
On Sat, 21 Apr 2018 at 6:46 PM, Andrew Gierth
wrote:
>
>
> So I dug into this one and it looks to me like the best approach. Here's
> a draft patch against 10-stable, if nobody can think of any showstoppers
> then I'll do the rest of the versions and commit them.
>
How does this guard against th
> "Amit" == Amit Kapila writes:
Amit> (c) Change the logic during rewrite such that it can detect this
Amit> situation and skip copying the tuple in the main table,
So I dug into this one and it looks to me like the best approach. Here's
a draft patch against 10-stable, if nobody can think
Hi all,
I have modified the PostgreSQL source code for my project implementation.
In the modified code, I am calling query_planner function several times
while I am inside the grouping planner function.
As the number of executions increase I have noticed memory leaks in the
code. I have pinpointe
12 matches
Mail list logo
