Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop redundant index #188

Merged
merged 1 commit into from
Jun 6, 2020
Merged

Drop redundant index #188

merged 1 commit into from
Jun 6, 2020

Conversation

krzyzak
Copy link
Contributor

@krzyzak krzyzak commented Jun 4, 2020

Hi 👋

I have rather small, hobbystic project that uses your gem. I've been checking which tables are the biggest among my project, and noticed this:

SELECT
-#    relname as "Table",
-#    pg_size_pretty(pg_total_relation_size(relid)) As "Size",
-#    pg_size_pretty(pg_total_relation_size(relid) - pg_relation_size(relid)) as "External Size"
-#    FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC;
┌───────────────────────────────┬─────────┬───────────────┐
│             Table             │  Size   │ External Size │
├───────────────────────────────┼─────────┼───────────────┤
│ que_scheduler_audit           │ 72 MB   │ 36 MB         │

For my amount of rows (given how simple single row is)

select count(*) from que_scheduler_audit;
┌────────┐
│ count  │
├────────┤
│ 846371 │
└────────┘
(1 row)

Time: 67.357 ms

I started investigating what exactly takes that much space.

 \d que_scheduler_audit;
                       Table "public.que_scheduler_audit"
┌──────────────────┬──────────────────────────┬───────────┬──────────┬─────────┐
│      Column      │           Type           │ Collation │ Nullable │ Default │
├──────────────────┼──────────────────────────┼───────────┼──────────┼─────────┤
│ scheduler_job_id │ bigint                   │           │ not null │         │
│ executed_at      │ timestamp with time zone │           │ not null │         │
└──────────────────┴──────────────────────────┴───────────┴──────────┴─────────┘
Indexes:
    "que_scheduler_audit_pkey" PRIMARY KEY, btree (scheduler_job_id)
    "index_que_scheduler_audit_on_scheduler_job_id" UNIQUE, btree (scheduler_job_id)
Referenced by:
    TABLE "que_scheduler_audit_enqueued" CONSTRAINT "que_scheduler_audit_enqueued_scheduler_job_id_fkey" FOREIGN KEY (scheduler_job_id) REFERENCES que_scheduler_audit(scheduler_job_id)

It seems that que_scheduler_audit have both PRIMARY KEY constraint index AND UNIQUE index on the same column, meaning that the latter one is essentially redundant, thus I created a PR that drops it.
After that change, I saved 18MB in my simple application:

┌───────────────────────────────┬─────────┬───────────────┐
│             Table             │  Size   │ External Size │
├───────────────────────────────┼─────────┼───────────────┤
│ que_scheduler_audit           │ 54 MB   │ 18 MB         │

@hlascelles
Copy link
Owner

Cheers very much for this @krzyzak. A perfect report... Really, it looks like you spent more time on the issue than on the fix! 👍

You are absolutely right, it looks redundant. I will have a look at getting this in as soon as possible. Thank you for you contribution!

@hlascelles hlascelles merged commit a2b61a3 into hlascelles:master Jun 6, 2020
@hlascelles
Copy link
Owner

Tests added to ensure one isn't readded: #191. Specifically here.

@hlascelles
Copy link
Owner

If you're interested in saving more space you can now run a built in audit clear down job: #193

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants