SELECT rid, r.fnm, (r.rm).upperleftx As ux, (r.rm).numbands As nb, (r.rbm).*
FROM (
SELECT
rid,
filename AS fnm,
ST_MetaData(rast) As rm,
ST_BandMetaData(rast,1) As rbm
FROM deyu.landsat where rid = 1) As r;

 upperleftx | upperlefty | width | height | scalex | scaley | skewx | skewy | srid | numbands 
------------+------------+-------+--------+--------+--------+-------+-------+------+----------
          0 |          0 |   600 |    900 |      1 |     -1 |     0 |     0 | 4236 |        1

postgis in-db vs out-db

in-db is where the source raster (tile) is stored in PostgreSQL. out-db only stores metadata describing the source raster in PostgreSQL and any functions in PostGIS will call the source raster files as needed. In my testing, out-db is slower than in-db. As to why out-db is slower, my suspicion is that PostgreSQL is able to cache the in-db data in its shared buffers while out-db requires calling the source file every time. – dustymugsAug 31 ‘12 at 17:12

Use the -R flag when using raster2pgsql to add the raster into PostGIS. The -R flag indicates that the raster will be stored out-of-db. All of the raster analysis functions in PostGIS will work but not the write functions, e.g. set pixel values, add bands. In my limited testing, the performance of out-of-db rasters is slower than in-db.http://postgis.refractions.net/documentation/manual-svn/using_raster.xml.html#RT_Raster_Loader