Home/ Questions/Q 7834829
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T13:20:44+00:00

I run a recipe website that uses PostgreSQL 9.1 as a backend. When a

  • 0

I run a recipe website that uses PostgreSQL 9.1 as a backend. When a user searches for recipes, I build a query on the fly depending on what the user wants to find. For example, if the user wants to find all recipes that have a cook time under 30 minutes, I would generate the query:

SELECT * From Recipes WHERE CookTime < 30;

I now have the need to “hide” certain recipes, meaning they will never show up in any search, ever. The only way to get to them would be knowing the URL directly. To do this, I’ve added a new column to the Recipes table:

ALTER TABLE Recipes ADD COLUMN Hidden boolean not null default false;
CREATE INDEX IDX_Recipes_Hidden ON Recipes(Hidden);

My idea is to just hard code the phrase “NOT HIDDEN” into every WHERE clause. For example, the query above would now be:

select * from recipes where not Hidden and CookTime < 30;

My Question:

According to the query analyzer, this will now generate a bitmap to combine the two indexes. Keep in mind 99% of the recipes will not be hidden. I want to know if this technique is the best, and fastest way to exclude certain recipes from all queries. I know the absolute fastest way would be to create a separate table for hidden recipes, however this would be a massive amount of re-factoring so I’d like to avoid this.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Do you have any performance issues? If there are no issues with your solution it makes no sense to waste more time on something that needs no change.

    A bitmap index is fine for something where you have not many different values. So in your case where you only have true and false it is fine.

    You could just build something like a materialized view but this seems to be to much work and it would be probably easier for you to just create a second table, but if you do not have any issues don’t change anything.

    MVs in postgres: http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views

    • 0