OK.
If you benchmark that correctly,
then it seems that adding some redundant search can get the query faster in
some special cases.
And without further info, I can not see any reason.
2015-08-14 14:35 GMT+09:00 Robert Campbell :
> Hi,
>
> My mistake, didnt apply the sub query properly the firs
Is the "Vacancy"."ID" a primary key?
Or is unique in Vacancy table?
Hi,
Doing this returns 0 records
On Thu, Aug 13, 2015 at 7:22 PM, 林士博 [via PostgreSQL] <
ml-node+s1045698n5862008...@n5.nabble.com> wrote:
> In the 'not exists' cluster, you do not have to search table "Vacancy as
> v" again.
> I think it would be faster to use the outer Vacancy table as below.
On Thu, Aug 13, 2015 at 10:09 AM, Josh Berkus wrote:
> Setup:
>
> * PostgreSQL 9.3.9
> * 1 master, 1 replica
> * Tiny database, under 0.5GB, completely cached in shared_buffers
> * 90% read query traffic, which is handled by replica
> * Traffic in the 1000's QPS.
>
> The wierdness:
>
> Periodical
Josh Berkus wrote:
> Periodically the master runs an "update all rows" query on the main
> table in the database. When this update hits the replica via
> replication stream, *some* (about 5%) of the queries which do seq scans
> will stall for 22 to 32 seconds (these queries normally take about
>
Setup:
* PostgreSQL 9.3.9
* 1 master, 1 replica
* Tiny database, under 0.5GB, completely cached in shared_buffers
* 90% read query traffic, which is handled by replica
* Traffic in the 1000's QPS.
The wierdness:
Periodically the master runs an "update all rows" query on the main
table in the dat
In the 'not exists' cluster, you do not have to search table "Vacancy as v"
again.
I think it would be faster to use the outer Vacancy table as below.
In your case, that do the same work.
NOT EXISTS (
SELECT 1
FROM "CategoryOption_TableRow" "ct126"
WHERE "Vacancy"."Template
