Zhuyi X.

Duplication in LLM Input/Output Fields: Expected Behavior?

I noticed in https://github.com/Arize-ai/openinference/blob/main/spec/semantic_conventions.md there are both input.value and llm.input_messages , looking at a real example shows the input messages are duplicated in these two fields, is that expected? Similar observations for output.value and llm.output_messages is also noticed.

2Comments

Commented on Tips to Speed Up Slow Search Sessions in Queries·Posted inPhoenix Support

Zhuyi X.

yeah, UI is also very fast. with user.id == "zhuyi" but I thought GIN is too specialized , we were just trying it out to see if it'll makes a diff at all. it works for =, but not strpos or like

Commented on Tips to Speed Up Slow Search Sessions in Queries·Posted inPhoenix Support

Zhuyi X.

this is the query after my update, it's the same slow.

Commented on Tips to Speed Up Slow Search Sessions in Queries·Posted inPhoenix Support

Zhuyi X.

wait, I see you used = instead of strpos in the query, which is why it's fast. our infra tried with gin index with {user, id}. if I change it to use strpos again, it's the same slow

Commented on Tips to Speed Up Slow Search Sessions in Queries·Posted inPhoenix Support

Zhuyi X.

how to tell if a query does join first or filtering first, is it based on the query plan? (I'm still not very good on reading these)

                                                                            QUERY PLAN                                                                             
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=17.02..25.48 rows=1 width=29)
   ->  Subquery Scan on candidate_spans  (cost=17.02..25.48 rows=1 width=29)
         Filter: ((candidate_spans.parent_id IS NULL) OR (NOT (SubPlan 1)))
         ->  Sort  (cost=17.02..17.03 rows=1 width=61)
               Sort Key: spans.start_time DESC NULLS LAST, spans.id DESC
               ->  Nested Loop  (cost=0.58..17.01 rows=1 width=61)
                     ->  Index Scan using ix_traces_project_rowid on traces  (cost=0.29..8.30 rows=1 width=4)
                           Index Cond: (project_rowid = 104)
                     ->  Index Scan using ix_spans_trace_rowid on spans  (cost=0.29..8.70 rows=1 width=33)
                           Index Cond: (trace_rowid = traces.id)
                           Filter: ((start_time >= '2025-09-08 00:00:00+00'::timestamp with time zone) AND ((attributes #>> '{user,id}'::text[]) = 'zhuyi'::text))
         SubPlan 1
           ->  Index Only Scan using uq_spans_span_id on spans spans_1  (cost=0.42..8.44 rows=1 width=0)
                 Index Cond: (span_id = (candidate_spans.parent_id)::text)
(14 rows)

Commented on Tips to Speed Up Slow Search Sessions in Queries·Posted inPhoenix Support

Zhuyi X.

hmm, it's pretty fast (100ms), is this query equivalent to what's used in the UI for filtering?

Commented on Tips to Speed Up Slow Search Sessions in Queries·Posted inPhoenix Support

Zhuyi X.

I was also a bit surprised to learn that the filtering happens before joining by project_id, otherwise the number of spans to extract json from would be much less. however it also makes sense given it feels filtering (non json columns) should usually be cheaper than join.

Commented on Tips to Speed Up Slow Search Sessions in Queries·Posted inPhoenix Support

Zhuyi X.

ok i see. so it’s probably an issue of combining large count and large average size (edited)

yeah, it does look like there is scaling issue with postgres for querying jsonb. btw, do you have insights in why langfuse uses clickhouse (https://langfuse.com/self-hosting) for saving traces, I wonder if it's because this problem. I don't have experience with clickhouse, but our company has some applications that use it, anecdotally, it's fast for json querying.

Commented on Tips to Speed Up Slow Search Sessions in Queries·Posted inPhoenix Support

Zhuyi X.

yeah, the scaling seems bad. 5s would still be not very good.

Commented on Tips to Speed Up Slow Search Sessions in Queries·Posted inPhoenix Support

Zhuyi X.

for spans table prod:

total # spans: 6m
table size: 100G
avg attribute size: 17kb

stg:

total # spans: 200k
table size: 1.5G
avg attribute size: 7kb

benchmark with the same query

 SELECT count(1) FROM spans WHERE spans.start_time >= '2025-09-08 00:00:00' and spans.start_time <= '2025-09-15 00:00:00' AND strpos(CAST((spans.attributes #>> '{user, id}') AS VARCHAR), 'zhuyi' ) > 0;

prod: 36s
stg: 0.2s.