Обсуждение: Help with database change

I am doing some research into partitioning my postgres database.  While doing this, I am trying to take the opportunity to improve the over all database.design.  One of the things I am thinking of implementing would be the use of nullif/coalesce.  Our application tends to send a lot of strings that only contain spaces.  While I know in the long run, the application needs to be fixed, I was thinking about using nullif and coalesce so the database can just store nulls in the database and save the space of storing "empty" strings as an interim fix.

My question is, how expensive is nullif and coalesce?  Can I expect to see a noticeable impact on performance if I do this?

Thanks,

Chris

Chris Hoover wrote:
> I am doing some research into partitioning my postgres database.
> While doing this, I am trying to take the opportunity to improve the
> over all database.design.  One of the things I am thinking of
> implementing would be the use of nullif/coalesce.  Our application
> tends to send a lot of strings that only contain spaces.  While I know
> in the long run, the application needs to be fixed, I was thinking
> about using nullif and coalesce so the database can just store nulls
> in the database and save the space of storing "empty" strings as an
> interim fix.
>
> My question is, how expensive is nullif and coalesce?  Can I expect to
> see a noticeable impact on performance if I do this?
>
> Thanks,
>
> Chris
My gut would say that it's not very expensive, unless you're using very
expensive regular expressions or already slow functions in expressions
with nullif, coalesce.

However, you can always run tests yourself. Just generate a bunch of
rows with dummy data and put them in a test database. There it's easy
enough to benchmark nullif and coalesce on your own terms and see how
much overhead they generate.

Peter