Hi PGML team,

I've been building out a system backed by PostgresML and wanted to share some feedback around my experience.

What's been going well:

• The general vision for PGML feels genuinely great. The ability to do embedding generation, model training and prediction all within SQL allows for some incredibly convenient system designs.
• Being able to just generate embeddings as computed columns is wonderful.

Pain Points / Oddities:

1. Vector Compatibility with Clustering Models

   • Clustering models don't seem to accept vectors directly when training or predicting.
     [XX000] ERROR: Unhandled type for quantitative scalar column: embeddings "vector"
   • Vectors seem to need to be cast as something like a real[].
   • This isn't really that big of a deal, it just strikes me as odd - when predicting, we end up needing both:
     • Embeddings as a real[] to predict on.
     • Embeddings as a vector for vector-to-vector comparisons.

2. User-Specific Model Training

   • This is where the product is unfortunately feeling genuinely unusable to me at the moment.
   • We're looking to train clustering models on per-user embeddings. Imagine something like below: a table partitioned by user such that we can pass an exact partition to .train
   • .train errors when encountering the user_id column:
     [XX000] ERROR: Unhandled type for quantitative scalar column: user_id "uuid"
   • There doesn't seem to be a way to inform PGML to ignore specific columns during training
   • There doesn't seem to be any other reasonable way of accomplishing this kind of training:
     • Subqueries can't be passed to .train in place of a relation name.
     • Tables or views per user with no actual reference to the user feel like far too big of a design smell to actually consider

CREATE TABLE user_embeddings
(
    user_id    uuid                    NOT NULL
        CONSTRAINT user_embeddings_user_id_pk
            PRIMARY KEY
        CONSTRAINT user_embeddings_user_id_fk
            REFERENCES users
            ON UPDATE RESTRICT ON DELETE CASCADE,
    embeddings vector(384)             NOT NULL
)
    PARTITION BY LIST (user_id);

Questions

• Am I missing something that would help solve for this per-user training situation?
• If not, should we start some discussion around how we might improve the ergonomics of .train such that a use case like the above could be designed around?
• Is it unreasonable to expect clustering model train & predict methods to accept vectors?