<div dir="ltr">Hi Dan,<br><div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-31 18:29 GMT+02:00 Dan Lyke <span dir="ltr"><<a href="mailto:danlyke@flutterby.com" target="_blank">danlyke@flutterby.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>So over this weekend I exported the entire database out and imported it<br>
into a new instance. Now that one table size is down to 34GB (from<br>
70GB before), which seems more in-line with the earlier database version<br>
(I guess something happened with extraneous data on import that got<br>
deleted).<br></blockquote><div><br></div><div>Well, this means that the 70GB were due to a consistent bloat present in<br></div><div>the data blocks. This means that the index was pointing to a larger number<br></div><div>of pages, since the information has been spread. The index scan plan was<br></div><div>necessary to inspect visibility of pages. So the planner chose the proper plan.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But the problem persists.<br>
<br>
This main table is 34G, we've got 3 other tables we use intensively, one<br>
is about 3.4G, the other two are 200M and 34M.<br>
<br>
We're running this on Amazon db.m3.2xlarge instances, so 8vCPU with 30G<br>
of RAM.</blockquote><div><br></div><div>Are you able to understand why the previous data import has grown up to 70GB?<br></div><div>Probably the key to understand why the plan has changed is to understand what<br></div><div>is changed in the meantime, also in terms of operations executed on the dataset. <br>I suspect that bloat is playing a key role here.<br><br></div><div>Giuseppe.<br></div></div><br></div></div></div>