Re: Target lists can have at most 1664 entries?

On Wed, 02 Jul 2008 15:24:38 +0800
Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> wrote:

> Tom Lane wrote:
> > =?UTF-8?Q?Bj=C3=B8rn?= T Johansen <btj(at)havleik(dot)no> writes:
> >> What does this mean and how can it be fixed?
> >
> > Reduce the number of columns in your SELECTs?
> >
> > This whiffs to me of excruciatingly bad schema design. How could you
> > possibly need upwards of a thousand columns in a query result?
> > IMHO reasonable column counts are O(10), not O(bignum).
>
> (I'm pretty new to Hibernate, so I can only share my general
> understanding, but:)
>
> One possible reason is that sometimes tools like Hibernate like to fetch
> records from multiple related tables in the database in one query with
> chained left joins. They then scan the results and eliminate duplicates
> where appropriate.
>
> It sounds horrifying, but it can actually be very fast where fairly
> small data sets are being fetched from highly normalized tables with
> appropriate indexes. In other circumstances, however, like when there
> are very high row counts or lots of fields being returned, it's a very
> bad strategy.
>
> My guess is that they haven't told Hibernate to use an appropriate
> fetching strategy (multiple SELECTs) for the data they're trying to
> load, and for some reason Hibernate is choosing a left join fetch. If
> they apply the appropriate annotations to their Hibernate data model or
> adjust their HQL queries to avoid "left join fetch" they might find that
> the problem goes away - and performance improves significantly.
>
> --
> Craig Ringer
>

Ok, guess we have to look at our Hibernate config.... (we are only using default fetching strategy...)

Thx...

BTJ