Hi,
On Fri, Jul 11, 2025 at 11:34 PM Andres Freund wrote:
> On 2025-07-11 11:22:36 +0900, Amit Langote wrote:
> > On Fri, Jul 11, 2025 at 5:55 AM Andres Freund wrote:
> > > On 2025-07-10 17:28:50 +0900, Amit Langote wrote:
> > > > Thanks for the patch.
> > > >
> > > > +/*
> > > > + * Use
Hi!
Andres, thank you for the explanation about the locks.
I've already tried to pass scan keys and saw that it is
quite expensive.
--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
Hi,
On 2025-07-11 14:03:42 +0300, Nikita Malakhov wrote:
> It's a pity I missed this thread when you developed the patch.
> I've developed a feature recently and discovered that SeqScan
> does not make use of scan keys, and there is a Tom Lane's
> comment regarding this:
> * Note that unlike Ind
Hi,
On 2025-07-11 11:22:36 +0900, Amit Langote wrote:
> On Fri, Jul 11, 2025 at 5:55 AM Andres Freund wrote:
> > On 2025-07-10 17:28:50 +0900, Amit Langote wrote:
> > > Thanks for the patch.
> > >
> > > +/*
> > > + * Use pg_assume() for != NULL tests to make the compiler realize no
> > >
Hi Amit!
It's a pity I missed this thread when you developed the patch.
I've developed a feature recently and discovered that SeqScan
does not make use of scan keys, and there is a Tom Lane's
comment regarding this:
* Note that unlike IndexScan, SeqScan never use keys in heap_beginscan
* (and
On Fri, Jul 11, 2025 at 5:55 AM Andres Freund wrote:
> On 2025-07-10 17:28:50 +0900, Amit Langote wrote:
> > On Thu, Jul 10, 2025 at 8:34 AM Andres Freund wrote:
> > > The performance gain unsurprisingly isn't significant (but seems
> > > repeatably
> > > measureable), but it does cut out a fair
Hi,
On 2025-07-10 17:28:50 +0900, Amit Langote wrote:
> On Thu, Jul 10, 2025 at 8:34 AM Andres Freund wrote:
> > On 2025-01-22 10:07:51 +0900, Amit Langote wrote:
> > > On Fri, Jan 17, 2025 at 2:05 PM Amit Langote
> > > wrote:
> > > > Here's v5 with a few commit message tweaks.
> > > >
> > > >
Hi Andres,
On Thu, Jul 10, 2025 at 8:34 AM Andres Freund wrote:
> On 2025-01-22 10:07:51 +0900, Amit Langote wrote:
> > On Fri, Jan 17, 2025 at 2:05 PM Amit Langote
> > wrote:
> > > Here's v5 with a few commit message tweaks.
> > >
> > > Barring objections, I would like to push this early next
Hi,
On 2025-01-22 10:07:51 +0900, Amit Langote wrote:
> On Fri, Jan 17, 2025 at 2:05 PM Amit Langote wrote:
> > Here's v5 with a few commit message tweaks.
> >
> > Barring objections, I would like to push this early next week.
>
> Pushed yesterday. Thank you all.
While looking at a profile I r
On Fri, Jan 17, 2025 at 2:05 PM Amit Langote wrote:
> Here's v5 with a few commit message tweaks.
>
> Barring objections, I would like to push this early next week.
Pushed yesterday. Thank you all.
--
Thanks, Amit Langote
Here's v5 with a few commit message tweaks.
Barring objections, I would like to push this early next week.
--
Thanks, Amit Langote
v5-0001-Refactor-ExecScan-to-allow-inlining-of-its-core-l.patch
Description: Binary data
Hi Junwang,
On Sat, Jan 11, 2025 at 7:39 PM Junwang Zhao wrote:
> Hi Amit,
>
> On Fri, Jan 10, 2025 at 7:22 PM Amit Langote wrote:
> >
> > On Fri, Jan 10, 2025 at 7:36 PM David Rowley wrote:
> > > On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> > > wrote:
> > > > In case of query
> > > > s
Hi Vladlen,
On Fri, Jan 10, 2025 at 11:49 PM Vladlen Popolitov
wrote:
> Amit Langote писал(а) 2025-01-10 18:22:
> > On Fri, Jan 10, 2025 at 7:36 PM David Rowley
> > wrote:
> >> On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> >> wrote:
> >> > In case of query
> >> > select count(*) from test
Hi Amit,
On Fri, Jan 10, 2025 at 7:22 PM Amit Langote wrote:
>
> On Fri, Jan 10, 2025 at 7:36 PM David Rowley wrote:
> > On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> > wrote:
> > > In case of query
> > > select count(*) from test_table where a_1 = 100;
> > > I would expect increase o
On Sat, Jan 11, 2025 at 4:57 PM Junwang Zhao wrote:
>
> On Fri, Jan 10, 2025 at 10:49 PM Vladlen Popolitov
> wrote:
> >
> > Amit Langote писал(а) 2025-01-10 18:22:
> > > On Fri, Jan 10, 2025 at 7:36 PM David Rowley
> > > wrote:
> > >> On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> > >> wrote
On Fri, Jan 10, 2025 at 10:49 PM Vladlen Popolitov
wrote:
>
> Amit Langote писал(а) 2025-01-10 18:22:
> > On Fri, Jan 10, 2025 at 7:36 PM David Rowley
> > wrote:
> >> On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> >> wrote:
> >> > In case of query
> >> > select count(*) from test_table wher
Amit Langote писал(а) 2025-01-10 18:22:
On Fri, Jan 10, 2025 at 7:36 PM David Rowley
wrote:
On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
wrote:
> In case of query
> select count(*) from test_table where a_1 = 100;
> I would expect increase of query time due to additional if...else . I
On Fri, Jan 10, 2025 at 7:36 PM David Rowley wrote:
> On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> wrote:
> > In case of query
> > select count(*) from test_table where a_1 = 100;
> > I would expect increase of query time due to additional if...else . It
> > is not clear
> > what code
On Fri, 10 Jan 2025 at 22:22, Amit Langote wrote:
>
> On Fri, Jan 10, 2025 at 1:06 PM David Rowley wrote:
> > I can look if performance tests show
> > that it might be worthwhile considering.
>
> Sure, that would be great.
What I wanted to know was if 0002 shows any additional gains over just
00
On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
wrote:
> In case of query
> select count(*) from test_table where a_1 = 100;
> I would expect increase of query time due to additional if...else . It
> is not clear
> what code was eliminated to decrease query time.
Are you talking about the c
Amit Langote писал(а) 2025-01-10 16:22:
On Fri, Jan 10, 2025 at 1:06 PM David Rowley
wrote:
On Fri, 10 Jan 2025 at 02:46, Amit Langote
wrote:
>
> On Mon, Jan 6, 2025 at 10:18 PM David Rowley wrote:
> > I've attached my workings of what I was messing around with. It seems
> > to perform about
On Fri, Jan 10, 2025 at 1:06 PM David Rowley wrote:
> On Fri, 10 Jan 2025 at 02:46, Amit Langote wrote:
> >
> > On Mon, Jan 6, 2025 at 10:18 PM David Rowley wrote:
> > > I've attached my workings of what I was messing around with. It seems
> > > to perform about the same as your version. I think
On Fri, 10 Jan 2025 at 02:46, Amit Langote wrote:
>
> On Mon, Jan 6, 2025 at 10:18 PM David Rowley wrote:
> > I've attached my workings of what I was messing around with. It seems
> > to perform about the same as your version. I think maybe we'd need
> > some sort of execScan.h instead of where I
On Mon, Jan 6, 2025 at 10:18 PM David Rowley wrote:
> On Sat, 21 Dec 2024 at 00:41, Amit Langote wrote:
> > To address (1), I tried assigning specialized functions to
> > PlanState.ExecProcNode in ExecInitSeqScan() based on whether qual or
> > projInfo are NULL. Inspired by David Rowley’s suggest
On Sat, 21 Dec 2024 at 00:41, Amit Langote wrote:
> To address (1), I tried assigning specialized functions to
> PlanState.ExecProcNode in ExecInitSeqScan() based on whether qual or
> projInfo are NULL. Inspired by David Rowley’s suggestion to look at
> ExecHashJoinImpl(), I wrote variants like Ex
Hi,
I’ve been looking into possible optimizations for ExecSeqScan() and
chatting with colleagues about cases where it shows up prominently in
analytics-style query plans.
For example, in queries like SELECT agg(somecol) FROM big_table WHERE
, ExecScan() often dominates the profile. Digging into i
26 matches
Mail list logo
