Prev: how to hack a webmail
Next: Patch for information_schema performance
From: Alvaro Herrera on 3 Dec 2009 08:42
Greg Stark escribi�:
> On Wed, Nov 25, 2009 at 1:03 AM, Konstantin Izmailov <pgfizm(a)gmail.com> wrote:
>
> > My question:�can pg_attribute.attnum be used to determine the sequential
> > ordinal positions of columns in a table? What is a right way to get the
> > ordinal numbers?
>
> You could use something like:
>
> row_number() over (partition by T.schemaname,T.viewname order by
> attnum) as "ORDINAL_POSITION"

Should we recast the attributes and columns views in information_schema?
I notice they still use attnum.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 3 Dec 2009 10:09
Alvaro Herrera <alvherre(a)commandprompt.com> writes:
> Should we recast the attributes and columns views in information_schema?
> I notice they still use attnum.

I'd vote against it, at least until we have something better than a
row_number solution. That would create another huge performance penalty
on views that are already ungodly slow.

When and if we get around to separating physical from logical column
position, the issue might go away "for free".

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Peter Eisentraut on 5 Dec 2009 09:46
On tor, 2009-12-03 at 10:09 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre(a)commandprompt.com> writes:
> > Should we recast the attributes and columns views in information_schema?
> > I notice they still use attnum.
>
> I'd vote against it, at least until we have something better than a
> row_number solution. That would create another huge performance penalty
> on views that are already ungodly slow.

Should be easy to test the performance impact of this, since the limit
for columns per table is 1600.


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: how to hack a webmail
Next: Patch for information_schema performance