> From: Claudio Freire [mailto:klaussfreire@xxxxxxxxx] > > How did you query the table's size? You're probably failing to account for TOAST tables. > > I'd suggest using pg_total_relation_size. ... On Mon, Mar 27, 2017 at 10:17 PM, Riaan Stander <rstander@xxxxxxxxx> wrote: > I'm using the first query from here. > https://wiki.postgresql.org/wiki/Disk_Usage Please don't top post. It's a surprisingly big difference. TOAST could be compressing the array, but I wouldn't expect it to be that compressible. Do you have any stats about the length of the site array per row? > The plan is to do the rights checking in the application. The join solution gets used for reports to filter data & client adhoc queries. Especially for reporting queries, you want the planner's stats to be as accurate as possible, and placing a literal sites arrays in the query in my experience is the best way to achieve that. But that is indeed limited to reasonably small arrays, thereby the need to have both variants to adapt the query to each case. If you can't afford to do that change at the application level, I would expect that the original schema without the array should be superior. The array hides useful information from the planner, and that *should* hurt you. You'll have to test with a reasonably large data set, resembling a production data set as much as possible. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
