From: | elein <elein(at)varlena(dot)com> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org, elein(at)varlena(dot)com |
Subject: | Re: How many fields in a table are too many |
Date: | 2003-06-29 03:39:54 |
Message-ID: | 200306282039.54073.elein@varlena.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Re: attribute ordering
The column presentation issue maybe should be
cross referenced with the problem with rowtypes
where the referenced table has dropped columns.
This is the one where in plpgsql you do a select *
into a rowtype of a table with dropped columns
you get a mismatch on the types. Implementing
the presentation ordering will probably give a
solution to the rowtype problem.
elein
On Saturday 28 June 2003 08:05, Jan Wieck wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> Is the issue of many columns in a tuple the same issue as a SELECT
> >> having many columns?
> >
> > I believe all the same inefficiencies need to be fixed whichever
> > way you look at it. Probably "many columns in SELECT" is the more
> > accurate description though.
>
> Together with the recent discussions about attribute reordering, it'd
> make sense, if we have a "resentation order" different from the actual
> physical tuple layout, that the table starts with all variable length
> fields at the end. This would give a better utilization of attribute
> offset caching.
>
> Don't know though, if this counts for much of the suffering.
>
>
> Jan
>
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
>
>
>
> --
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #================================================== JanWieck(at)Yahoo(dot)com #
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
>
--
=============================================================
elein(at)varlena(dot)com Database Consulting www.varlena.com
PostgreSQL General Bits http:/www.varlena.com/GeneralBits/
"Free your mind the rest will follow" -- en vogue
From | Date | Subject | |
---|---|---|---|
Next Message | Toni Schlichting | 2003-06-29 08:41:36 | Re: How many fields in a table are too many |
Previous Message | Robert L Mathews | 2003-06-29 03:31:22 | libpq.so.2 and postgresql-libs-7.3.3 RPM |