You can do all of this in one step, eg,

raster2pgsql -c -s 27700 -C -I -f rast *.asc -t 100x100 stg.COUNTRY_1M 
| psql -U treex -d data_processing -h localhost

-c means create, which is the default. Because you can use *.asc, there is no need to use

for i in $(ls *.asc); do raster2pgslq ...; done

type logic, as all asc files will be passed to raster2pgsql, and this will avoid the error you are seeing of trying to add tiles to a table that already has contraints on.

As as aside, from your previous question, I know that this is UK LIDAR, which is quite a large dataset. You would be well advised to use -t switch to tile you input, where tile size is expressed in pixels, eg, -t 100x100. Something in the range of 100-200 pixels seems to work well.

There is not that much literature on this, though this blog outlines some of the effects of tile size on performance.

As you can see from the image below, polygon/raster overlay functions get much faster with smaller tile sizes, which makes sense, to a point. I was doing lots of vector buidling/LIDAR tile queries, and found tiling led to an order of magnitude improvement in query time. Obviously, this will depend somewhat on the size of your vectors.

You can do all of this in one step, eg,

raster2pgsql -c -s 27700 -C -I -f rast *.asc -t 100x100 stg.COUNTRY_1M 
| psql -U treex -d data_processing -h localhost

-c means create, which is the default. Because you can use *.asc, there is no need to use

for i in $(ls *.asc); do raster2pgslq ...; done

type logic, as all .asc files will be passed to raster2pgsql, and this will avoid the error you are seeing of trying to add tiles to a table that already has constraints on.

As an aside, from your previous question, I know that this is UK LIDAR, which is quite a large dataset. You would be well advised to use -t switch to tile you input, where tile size is expressed in pixels, eg, -t 100x100. Something in the range of 100-200 pixels seems to work well.

There is not that much literature on this, though this blog outlines some of the effects of tile size on performance.

As you can see from the image below, polygon/raster overlay functions get much faster with smaller tile sizes, which makes sense, to a point. I was doing lots of vector building/LIDAR tile queries, and found tiling led to an order of magnitude improvement in query time. Obviously, this will depend somewhat on the size of your vectors.

You can do all of this in one step, eg,

raster2pgsql -c -s 27700 -C -I -f rast *.asc -t 100x100 stg.COUNTRY_1M 
| psql -U treex -d data_processing -h localhost

-c means create, which is the default. Because you can use *.asc, there is no need to use

for i in $(ls *.asc); do raster2pgslq ...; done

type logic, as all asc files will be passed to raster2pgsql, and this will avoid the error you are seeing of trying to add tiles to a table that already has contraints on.

As as aside, from your previous question, I know that this is UK LIDAR, which is quite a large dataset. You would be well advised to use -t switch to tile you input. Something in the range of 100-200 pixels seems to work well.

You can do all of this in one step, eg,

raster2pgsql -c -s 27700 -C -I -f rast *.asc -t 100x100 stg.COUNTRY_1M 
| psql -U treex -d data_processing -h localhost

-c means create, which is the default. Because you can use *.asc, there is no need to use

for i in $(ls *.asc); do raster2pgslq ...; done

type logic, as all asc files will be passed to raster2pgsql, and this will avoid the error you are seeing of trying to add tiles to a table that already has contraints on.

As as aside, from your previous question, I know that this is UK LIDAR, which is quite a large dataset. You would be well advised to use -t switch to tile you input, where tile size is expressed in pixels, eg, -t 100x100. Something in the range of 100-200 pixels seems to work well.

There is not that much literature on this, though this blog outlines some of the effects of tile size on performance.

As you can see from the image below, polygon/raster overlay functions get much faster with smaller tile sizes, which makes sense, to a point. I was doing lots of vector buidling/LIDAR tile queries, and found tiling led to an order of magnitude improvement in query time. Obviously, this will depend somewhat on the size of your vectors.