Re: Improving performance with a Function instead of a

From: Mike Mascari <mascarm(at)mascari(dot)com>
To: Hadley Willan <hadley(dot)willan(at)deeperdesign(dot)co(dot)nz>
Cc: PGSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Improving performance with a Function instead of a
Date: 2004-02-05 00:31:33
Message-ID: 40218EE5.7060101@mascari.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hadley Willan wrote:

> Hi all,
> I am using some views now to put together a particular format for
> my Java client factory to produce Java Beans from the database.
>
> Because we support internationalisation we are representing values as
> an id then storing their multiple languages in unicode to support the
> same repesentation at the database.
>
> This format is:
>
> base_table, id bigint, is_disabled boolean default false.
>
> resource_table, foreign_key_to_base_table, locale_foreign_key,
> display_name, is_translated
>
> As such, my views are quite slow because there are a number of Right
> Joins occuring so that I can present a single "locale" field in the
> view that all the localised information will attach to correctly.
>
> That way I can > select * FROM v_object where locale = 'en_GB' and
> object_id = 120031;

Without taking the view definition into account, the above query could
not use an index on object_id because it is of type 'bigint', but the
integer constant is parsed as 'integer'. It must either be rewritten as:

object_id = 120031::bigint

or

object_id = '120031'

or set the sequence for this identifier to start fetching values > 4.2
billion (32-bit numbers). Of course, the view definition may have other
optimization possibilities as well...

Mike Mascari

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marc A. Leith 2004-02-05 02:21:22 Re: Predictive or scoring solution for PostgreSQL ?
Previous Message Gaetano Mendola 2004-02-05 00:20:56 Re: pg_generate_sequence and info_schema patch (Was: SELECT