On Thu, Jun 26, 2003 at 01:19:09PM +0530, Shridhar Daithankar wrote:
> On 26 Jun 2003 at 3:44, [EMAIL PROTECTED] wrote:
> > > On Thu, Jun 26, 2003 at 03:17:12AM -0400, [EMAIL PROTECTED]
> > > wrote:
> > >> > I have a table with 13 fields. Is that
> > >> > too many fields for one table.
> > >> > Mar
elein wrote:
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
Hi Mark,
actually there is a simple way to determine this.
create an entity relationship model, try to build a 3rd normal form,
look on what the users/customers are really doing, not only what data
they are dealing with and finally break up the 3rd NF again.
A table with too many columns is as
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.
On Sat, Jun 28, 2003 at 02:21:57PM -0400, Tom Lane wrote:
> Right, I was just thinking of this as an optimization we'd apply during
> initial table creation. Renumbering columns later on would be a huge
> mess, far more work than the optimization is worth.
perhaps it could be done on VACUUM ?
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > However, I am not sure how useful NOT NULL is in practice because there
> > are lots of columns that don't specify NOT NULL but have mostly nulls or
> > mostly non-nulls, which kills our caching --- what I was hoping to do
> > some day
Bruce Momjian <[EMAIL PROTECTED]> writes:
> However, I am not sure how useful NOT NULL is in practice because there
> are lots of columns that don't specify NOT NULL but have mostly nulls or
> mostly non-nulls, which kills our caching --- what I was hoping to do
> some day was to cache the null bit
Alvaro Herrera wrote:
On Sat, Jun 28, 2003 at 01:43:32PM -0400, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this a TODO?
>When columns can be reordered, move varlena columns to the end?
I believe that really what you want is fixed-width NOT NULL columns
first, then fixed-widt
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> This means that when you do ALTER TABLE ... SET/DROP NOT NULL the table
>> may have to be completely rewritten?
> I don't think we would change any physical ordering with ALTER TABLE ---
> just do it when the table is created, if
Alvaro Herrera wrote:
> On Sat, Jun 28, 2003 at 01:43:32PM -0400, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Is this a TODO?
> > > When columns can be reordered, move varlena columns to the end?
> >
> > I believe that really what you want is fixed-width NOT NULL columns
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this a TODO?
> > When columns can be reordered, move varlena columns to the end?
>
> Yeah, if it's not in there already. I remember seeing some Berkeley-era
> comments speculating that this would be a good thing to do. Not su
On Sat, Jun 28, 2003 at 01:43:32PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this a TODO?
> > When columns can be reordered, move varlena columns to the end?
>
> I believe that really what you want is fixed-width NOT NULL columns
> first, then fixed-width nullab
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this a TODO?
> When columns can be reordered, move varlena columns to the end?
Yeah, if it's not in there already. I remember seeing some Berkeley-era
comments speculating that this would be a good thing to do. Not sure if
they're still in the
Is this a TODO?
When columns can be reordered, move varlena columns to the end?
---
Jan Wieck wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Is the issue of many columns in a tuple the
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> 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
There is an article on normalisation at IBM developer works for all
those who need a primer on table normalisation.
I learnt this from, would you believe, "dBase Mac" by Jim Heid when I
was one of the two users in the world running that version in 1988-1989
=:-D
I recomend "Database Application P
Bruce Momjian <[EMAIL PROTECTED]> 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.
Is the issue of many columns in a tuple the same issue as a SELECT
having many columns?
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Added to TODO:
> > * Improve performance for queries with many c
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
> * Improve performance for queries with many columns
> We already have an item for tables with many columsn.
That one's a duplicate then.
regards, tom lane
---(end of broadcast)-
Added to TODO:
* Improve performance for queries with many columns
We already have an item for tables with many columsn.
---
Tom Lane wrote:
> <[EMAIL PROTECTED]> writes:
> >> As long as we are playing "who's is bi
<[EMAIL PROTECTED]> writes:
>> As long as we are playing "who's is biggest", I have one with 900+
>> attributes (normalized) but there is a big warning - if you have a
>> query that returns hundreds of columns it will be very, very slow.
> Is the SELECT * the only circumstance? That is, if you spe
> The original developers didn't really have a concept of storing different
> info in different tables.
That kind of stuff drives me nuts. Where do people get their CS degrees?
It took me less that 2 days to teach our ARTISTS how to construct
fully-normalized tables (it's a long story as to why I
On Thu, Jun 26, 2003 at 01:02:06 -0400,
Mike Mascari <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Just a quick question, not unrelated to my
> > previous question, which I don't think will
> > get answered. I have a table with 13 fields.
> > Is that too many fields for one table.
>
> Mathematicall
On 26 Jun 2003 at 3:44, [EMAIL PROTECTED] wrote:
> > On Thu, Jun 26, 2003 at 03:17:12AM -0400, [EMAIL PROTECTED]
> > wrote:
> >> > I have a table with 13 fields. Is that
> >> > too many fields for one table.
> >> > Mark
> >> Thirteen? No way. I've got you beat with 21:
> > Pfft! Is *that* all? I'v
> On Thu, Jun 26, 2003 at 03:17:12AM -0400, [EMAIL PROTECTED]
> wrote:
>> > I have a table with 13 fields. Is that
>> > too many fields for one table.
>> > Mark
>> >
>>
>> Thirteen? No way. I've got you beat with 21:
>
> Pfft! Is *that* all? I've got a table with 116 fields.
I *knew* a number of
On Thu, Jun 26, 2003 at 03:17:12AM -0400, [EMAIL PROTECTED] wrote:
> > I have a table with 13 fields. Is that
> > too many fields for one table.
> > Mark
> >
>
> Thirteen? No way. I've got you beat with 21:
Pfft! Is *that* all? I've got a table with 116 fields. Very soon we'll be
upgrading to 7.
26 matches
Mail list logo
