From: | "Dann Corbit" <DCorbit(at)connx(dot)com> |
---|---|
To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Selecting a constant question |
Date: | 2007-06-11 19:55:55 |
Message-ID: | D425483C2C5C9F49B5B7A41F8944154701000709@postal.corporate.connx.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Gregory Stark [mailto:stark(at)enterprisedb(dot)com]
> Sent: Monday, June 11, 2007 12:48 PM
> To: Dann Corbit
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] Selecting a constant question
>
> "Dann Corbit" <DCorbit(at)connx(dot)com> writes:
>
> > SELECT 1 FROM test.dbo.a_003
> >
> > gets about 60,000 records per second
> >
> > SELECT '1' FROM test.dbo.a_003
> >
> > gets about 600 records per second.
> >
> > The cause is that postgres describes the return column as "unknown"
> > length 65534 in the 2nd case.
>
> Wait, back up. How does this cause it to go slower?
The issue is this:
Postgres describes the column with a typmod of -1 (unknown) and a length
of 65534.
This means that any client application must reserve 65534 bytes of
spaces for every row of data (like a grid control for example), which
postgres should know (and report) that the maximum length of the column
is 1.
This is not a PSQL issue, it's an issue with other products relying on
the accuracy of the reported postgres metadata for a given SQL
statement.
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2007-06-11 20:04:04 | Re: Selecting a constant question |
Previous Message | Gregory Stark | 2007-06-11 19:48:22 | Re: Selecting a constant question |