[zzorphcreator]

just tried from claude code.

some observations: setup (without openai embeddings) was pretty easy. Nice! Not sure why it took ~19 minutes for a postgres database with 20sh tables. Also the data from pg_desc did not get into the wiki

I am going to try to embed it in our agentic flow and see how it fits. Very cool project though.

[andreybavt]

Hi, thanks for trying it! 19m for ~20 tables is slower that I'd expect, I assume you activated historic queries, right? As Luca said we're focusing on performance improvements right now. 99% of the latency is LLM calls, so we're optimizing them.

As for the descriptions: `pg_description` should be used already, we store raw pg descriptions in the semantic-layer/<connection>/_schema/*.yaml files under descriptions.db. there's also an AI generated description next to it. AI is the combination of the raw DB description + bunch of metadata we manage to collect about a table/column.

could you run `ktx sl` and see if the descriptions appear in the CLI ?

also feel free to join our community Slack - ktx.sh/slack We'll be happy to help with other questions

[lucamrtl]

Thanks for the feedback - the length is typically because we’re also processing query history to infer acceptable joins, etc. But we have a lot of optimizations to implement, so we’re positive this will run faster in the coming weeks. Looking into the pg_desc issue now, thanks for reporting!

[zzorphcreator]

Thank you both. I will do more digging on pg_description as you suggested. Also looking forward to optimizations. I was actually working on the similar project on the semantic data layer for llm context, but I think your project already solves this issue. Will report back as I try to integrate ktx more in our agentic flows.

[lucamrtl]

Nice! Feel free to join our slack community btw: ktx.sh/slack

we always like chatting with folks that have tried building similar projects in the past

[zzorphcreator]

Cool. Just joined.