Re: Selecting a constant question - Mailing list pgsql-hackers

From Larry McGhaw
Subject Re: Selecting a constant question
Date
Msg-id D425483C2C5C9F49B5B7A41F89441547013DB278@postal.corporate.connx.com
Whole thread Raw
In response to Re: Selecting a constant question  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Selecting a constant question  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Selecting a constant question  (Brian Hurt <bhurt@janestcapital.com>)
List pgsql-hackers
I'm really frustrated by this process I'm not trying to attack anyone
here.  I'm just surprised that no one will even entertain the idea that
this is an issue that needs to be addressed.

Instead nearly all of the responses have been attacking the applications
that rely on the metadata.

Let me back up and explain the situation.

This issue came to light for us when we were using a query tool to
examine performance of postgres queries.

We were not only measuring the performance of the database itself, but
also the TCP/IP transport,
And the rendering of the data .. Comparing SQL Server, Oracle, and
Postgres head to head with the same queries.

We noticed inexplicably that when we used a constant with a postgres
query, our records per second dropped
From 60,000 records per second to 600 records per second, so we started
digging into the issue.

We discovered that libpq was not describing the metadata properly for
the constant column, and it appears
That the 3rd party grid control was relying on that metadata somehow  ..
The bottom line is that there was
A huge performance drag.

* OK ... I agree that the memory handling in the grid control could be
better, but I would imagine that
this issue is not an isolated to this one particular control, and that
other applications and controls that rely
on resultset metadata may have this issue.

Bottom line,  we only reported this problem because we thought you would
be interested in doing everything possible to make postgres more
mainstream and conform to SQL standards.  In the past such suggestions
have been absorbed with zeal.

I have no vested interest in you improving the interface or not, and I'm
not going to "plead a case" for you
To do something that every other commercial database has done out of the
box.

It is in your hands now :)

Thanks

lm

-----Original Message-----
From: Andrew Dunstan [mailto:andrew@dunslane.net]
Sent: Tuesday, June 12, 2007 4:50 AM
To: Larry McGhaw
Cc: Hannu Krosing; Tom Lane; Alvaro Herrera; Dann Corbit; Gregory Stark;
Martijn van Oosterhout; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant question



Larry McGhaw wrote:
> Again, the issue is not our tool, but the deficiency in libpq/postgres

> ... even mysql gets its right  .. why not Postgres?
>
> Its not hard for a database to report metadata properly.
>
> if I issue a sql statement:
> select '123' from <any table>
> the database should report that the maximum length of the 1st column
> in the resultset is 3 ... it cant be any more plain than that.
>
>
>

Making assertions like this does not make your case for you. If you
think it's that easy then send in a patch. I suspect that doing what you
want in the cases where it could be supported would require a protocol
change, with possibly an extra field in the RowDescription object. If
that's true you'd need to make a very good and compelling case indeed
for such a change. If this is so vital I'm curious to know why driver
authors haven't been screaming about it until now. I'm not dismissing
what you want, but just waving your hand and saying "it's not hard"
really won't do.

cheers

andrew




pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: regression driver changes vs resultmap
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Selecting a constant question