On Thu, Jun 05, 2025 at 07:42:48AM -0500, Sami Imseih wrote:
> v5 attached.
I'm OK with this version, so switching that as ready for committer.
--
Michael
signature.asc
Description: PGP signature
> + * If an direction_keyword (i.e., FETCH FORWARD) is used, set this field
> + * to distinguish it from its numeric counterpart (i.e., FETCH 1). This
> + * value is set only within gram.y.
>
> One nitpick comment here is that I would have mentioned that this
> matters for query jumbling.
Done
On Wed, Jun 04, 2025 at 11:51:56AM -0500, Sami Imseih wrote:
>> An enum would shine here IMO, because the value could be
>> self-documented and one would not need to guess what each integer
>> value means. That could be something like a direction_keyword, filled
>> with FETCH_KEYWORD_LAST, FETCH_K
> Hmm. I was not sure if we'd really need to get down to that, as most
> of the grammar keywords have the same parsed meaning, but there's a
> good point with LAST for example that uses a negative value for
> howMany. If we silence the number, LAST would map with everything
> else that has FETCH_
On Tue, Jun 03, 2025 at 01:04:36PM -0500, Sami Imseih wrote:
> v3 is what I'm thinking: In FetchStmt, introduce a new field called
> explicit_direction (maybe there's a better name?), which is an int that
> we can assign a value to in gram.c. The value will be 0 if no explicit
> direction is used.
> Hmm, we could do that to differentiate the keyword ALL. I had a thought
> earlier about differentiating the other keywords as well: FIRST, LAST,
> BACKWARD, FORWARD, and ABSOLUTE. Initially, I thought it might
> be a bit too much, but I do see the merit in this approach, as these are
> syntactica
> Should we offer something more consistent with DeallocateStmt, where
> we have a boolean flag that would be set when ALL is specified,
> included in the jumbling? This would mean two separate entries: one
> for the constants and one for ALL.
Hmm, we could do that to differentiate the keyword AL
On Mon, Jun 02, 2025 at 02:44:36PM -0500, Sami Imseih wrote:
> Since the FETCH case is clear-cut, here is a patch that normalizes variable
> fetch sizes in a FETCH command. At a minimum, we can apply this patch.
> I’ve also added tests in pg_stat_statements utility.sql to demonstrate
> how queryIds
> > The FETCH and CLOSE are already not clear to what underlying SQL
> > they are referring to, and there is not much chance to actually
> > improve that unless
> > we track a cursor queryId in pg_stat_statements ( at that point we can show
> > that
> > FETCH or CLOSE refer to this specific cursor
> > postgres_fdw, as an example, in which cursor name get reused
> > for different queries. Notice below "c1" and "c2" is reused for different
> > queries, so now what underlying sql is FETCH, i.e. FETCH 100 FROM c1
> > referring
> > to? v2-0001 does not help us with the FETCH problem
> > because
On Fri, May 02, 2025 at 04:21:21PM -0500, Sami Imseih wrote:
> postgres_fdw, as an example, in which cursor name get reused
> for different queries. Notice below "c1" and "c2" is reused for different
> queries, so now what underlying sql is FETCH, i.e. FETCH 100 FROM c1 referring
> to? v2-0001 does
> Hmm. What are the workloads that you have seen as problematic? Do
> these involve cursor names generated randomly, where most of them are
> similar with a random factor for the name?
postgres_fdw, as an example, in which cursor name get reused
for different queries. Notice below "c1" and "c2"
On Wed, Apr 30, 2025 at 02:43:41PM -0500, Sami Imseih wrote:
> I also want to add that the decision to not normalize the cursor name in
> the FETCH command is because it would not make sense to combine
> FETCH commands for various cursors into the same entry.
- calls | rows |
Hi hackers,
I recently looked into a workload that makes heavy use of explicit cursors,
and I found that pg_stat_statements can become a bottleneck. The
application in question declares hundreds of cursors, and for each one,
performs many FETCH and MOVE operations with varying fetch sizes.
As a r
I forgot to add the proper tests to the Normalize cursor utility statements.
Reattaching v2.
I also want to add that the decision to not normalize the cursor name in
the FETCH command is because it would not make sense to combine
FETCH commands for various cursors into the same entry.
Regards,
-
15 matches
Mail list logo
