<div dir="ltr">Maybe no downside, it's just my background with gis systems that makes me think the wrong way. I was looking at the PCID table as a kind of spatial-reference table, where you can re-use every reference over and over for different tables with geometry. Up to now it served us ok to deal with multiple input files using the same PCID, but I can see the limitations. <div><br></div><div>In the end we might have to deal with partitions as well, since disks are getting full. Is there any writing (articles, blog) you can share about your experiences?</div><div><br></div><div>Best,</div><div> Tom</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 5 Oct 2015 at 15:31 Howard Butler <<a href="mailto:howard@hobu.co">howard@hobu.co</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Oct 5, 2015, at 8:03 AM, Tom van Tilburg <<a href="mailto:tom.van.tilburg@gmail.com" target="_blank">tom.van.tilburg@gmail.com</a>> wrote:<br>
><br>
> I am writing over a thousand laz files, all using the same PCID.<br>
> Does this mean that I should better create one PCID for every file that I import?<br>
<br>
Is there a downside to that strategy? You very likely want to have partitioned tables anyway, so you can quickly drop big chunks of data if you need. When our CRREL group manages a huge Oracle point cloud database, we utilize the partitioning approach which necessitates individual pcid (we group a bunch of logically-together files into a a single partition as needed) for each file.<br>
<br>
You can use the post_sql option of the driver to write to a specific column for the specific file as you are loading. This would allow you to get the arrangement you want. It's not clear that you should work so hard to achieve it, though that's probably a question for the database folks rather than myself.<br>
<br>
Howard</blockquote></div>