From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | Victor Blomqvist <vb(at)viblo(dot)se> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Limit Heap Fetches / Rows Removed by Filter in Index Scans |
Date: | 2016-08-20 09:21:42 |
Message-ID: | CA+bJJbzUsuc38Gn4=b-t+euWbKZ+ZQMvOm-QVmn_rrrN-0bHyQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Victor:
On Fri, Aug 19, 2016 at 8:01 PM, Victor Blomqvist <vb(at)viblo(dot)se> wrote:
> Thanks! A sub select seems to do it.
I suspected it would be needed, that's why I sugested it.
I prefer to write the queries as CTEs because they are much easier to
read, but IIRC they are some kind of 'optimization fences'. Some times
I end up using psql macros to write queries in CTE-like order in my
scripts and compose them into sub selects when I have this problems.
> Checking these two queries I can see that the first one visits the
> max 50 rows its allowed to and returns 5 rows, while the second one
> finish off after 13 rows fetched and returns the full 10 rows.
Good. The only problem is you are not guaranteed a result, like in the
contrived example I gave, but if it is what you want this is a way to
go.
Francisco Olarte.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2016-08-20 19:04:05 | endash not a graphic character? |
Previous Message | Sameer Kumar | 2016-08-20 00:48:50 | Re: PG vs ElasticSearch for Logs |