On Fri, 6 Sept 2024 at 18:30, Ashutosh Bapat
wrote:
> If the patches are applied in the order 0001, 0003 and 0002, the size
> of the structure remains 632 throughout. Patch 0003 does not affect
> the size of the structure by itself.
Yeah. I kept 0003 separate so it could be easily tested independ
On Wed, Sep 4, 2024 at 8:20 PM David Rowley wrote:
>
> On Mon, 19 Aug 2024 at 22:01, David Rowley wrote:
> > To try and move this forward again, I adjusted the patch to use a
> > static function with pg_noinline rather than unlikely. I don't think
> > this will make much difference code generati
On Mon, 19 Aug 2024 at 22:01, David Rowley wrote:
> To try and move this forward again, I adjusted the patch to use a
> static function with pg_noinline rather than unlikely. I don't think
> this will make much difference code generation wise, but I did think
> it was an improvement in code clean
On Thu, 18 Jul 2024 at 19:56, Andy Fan wrote:
> I'm curious about why a 'unlikey' change can cause noticeable change,
> especially there is just one function call in the 'if-statement' (I am
> thinking more instrucments in the if-statement body, more changes it can
> cause).
>
> + if (unlike
Ashutosh Bapat writes:
> On Fri, Jul 12, 2024 at 11:59 AM Ashutosh Bapat
> wrote:
>>
>>
> Out of curiosity, I measured the performance with just the "unlikely"
> change and with the full patch. Below are the results
> Testing with 100 partitions
...
> latency average = 333.538 ms
>
> with ju
On Fri, Jul 12, 2024 at 11:59 AM Ashutosh Bapat
wrote:
>
>
> Now that you are also seeing the slowdown with your earlier patch, I
> am wondering whether adding unlikely() by itself is a good
> optimization. There might be some other reason behind the perceived
> slowdown. How do the numbers look w
On Thu, Jul 11, 2024 at 5:39 PM David Rowley wrote:
>
> On Wed, 10 Jul 2024 at 02:42, Ashutosh Bapat
> wrote:
> > Observations
> > 1. The numbers corresponding to 10 and 100 partitions are higher when
> > patched. That might be just noise. I don't see any reason why it would
> > impact negatively
> @@ -2684,6 +2726,14 @@ ExecEndWindowAgg(WindowAggState *node)
> PlanState *outerPlan;
> int i;
>
> + if (node->buffer != NULL)
> + {
> + tuplestore_end(node->buffer);
> +
> + /* nullify so that release_partition skips the
> tuple
Hi David,
Thank you for the patch.
> I think this might just be noise as a result of rearranging code. In
> terms of C code, I don't see any reason for it to be slower. If you
> look at GenerationDelete() (as what is getting called from
> MemoryContextDelete()), it just calls GenerationReset().
Em qui., 11 de jul. de 2024 às 09:09, David Rowley
escreveu:
> On Wed, 10 Jul 2024 at 02:42, Ashutosh Bapat
> wrote:
> > Observations
> > 1. The numbers corresponding to 10 and 100 partitions are higher when
> > patched. That might be just noise. I don't see any reason why it would
> > impact ne
On Sun, Jul 7, 2024 at 4:27 PM David Rowley wrote:
>
> As part of making tuplestores faster [1], I noticed that in WindowAgg, when
> we end one partition we call tuplestore_end() and then we do
> tuplestore_begin_heap() again for the next partition in begin_partition() and
> then go on to set u
As part of making tuplestores faster [1], I noticed that in WindowAgg, when
we end one partition we call tuplestore_end() and then we do
tuplestore_begin_heap() again for the next partition in begin_partition()
and then go on to set up the tuplestore read pointers according to what's
required for t
12 matches
Mail list logo
