[Q&A] What should the key_field be for a partitioned table?

[abdelfattahradwan]

What happens?

Let's say I have the following table:

create table logging.logs (
  timestamp timestamptz not null,
  uuid uuid not null,
  data jsonb,
  primary key (timestamp, uuid)
) partitioned by range (timestamp);

When creating a BM25 index, what field should be used as the key_field? Should it be the name of the created primary key constraint or what? And how would queries like the one from the docs, for example:

SELECT id, description, rating, category
FROM mock_items
WHERE id @@@ pdb.more_like_this(3)
ORDER BY id;

Look like when the table is partitioned and the id is not a single column?

To Reproduce

N/A

OS:

Debian GNU/Linux 12 (bookworm)

ParadeDB Version (e.g. output of SELECT * FROM paradedb.version_info();):

0.21.4

Are you using ParadeDB Docker, Helm, or the extension standalone?

ParadeDB pg_search Extension

Full Name:

Abdelfattah Radwan

Affiliation:

KZ Development

Did you include all relevant data sets for reproducing the issue?

Yes

Did you include the code required to reproduce the issue?

• Yes, I have

Did you include all relevant configurations (e.g., CPU architecture, PostgreSQL version, Linux distribution) to reproduce the issue?

• Yes, I have

[jamessewell]

This is one of the rough edges in our current API.

Currently you must set a unique field as key_field for BM25, but in a temporal table such as this the PK is timestamp,uuid. You could just use uuid - but obviously this isn't correct (although it will work in most places, MLK above is one it won't).

There is a PR I've written (#3807) which fixes this, it's a fairly large change but I'm hopeful we will be able to merge it soon. In this new world you don't set key_field, it just infers it (including a composite column value) from your unique indexes.

[abdelfattahradwan]

Thanks for the information and for the excellent work on the PR 🙏🏻