Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dONBA-0003N5-S7 for pgsql-performance@arkaria.postgresql.org; Fri, 23 Jun 2017 11:55:12 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dONBA-000491-8E for pgsql-performance@arkaria.postgresql.org; Fri, 23 Jun 2017 11:55:12 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dONB8-00046s-O6 for pgsql-performance@postgresql.org; Fri, 23 Jun 2017 11:55:10 +0000 Received: from mailgw04.hosei.ac.jp ([133.25.1.24]) by makus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dONB3-0007jk-Bj for pgsql-performance@postgresql.org; Fri, 23 Jun 2017 11:55:08 +0000 Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197]) by mailgw04.hosei.ac.jp (Postfix) with ESMTP id EB1B11D582FB for ; Fri, 23 Jun 2017 20:54:55 +0900 (JST) Authentication-Results: mailgw04.hosei.ac.jp; sender-id=none header.from=akihiko.odaki.4i@stu.hosei.ac.jp; spf=none smtp.mfrom=akihiko.odaki.4i@stu.hosei.ac.jp Received: by mail-io0-f197.google.com with SMTP id r24so40286817ioi.8 for ; Fri, 23 Jun 2017 04:54:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IaHGlkao/JxqYe4AyxYbOZ9KXHiTODv+lIDNoBtafN8=; b=JDnve5qNAU8pJcw805OQgj5Swt1JmUs6baNBwjI2fkQ9MXCIm7mZnILGNhkpS5UyzE 9XSSovvBPvOrysSU1DBNvtng6/feJr2V8vFRBR52A6K+ywAK0NwOywbsh2YltGru46nU BlHCvh4trVvc/1xuC6CzU7mfyZM/CWDev6Ud72AWgwOc75/kjKUxNqPJcsM1G388PMHW q5MCuKabL0kM8fuyI9/2Ke4klr4kF4QH2TuhrhNG9BzHQcow3ZS7d6/CaweLzjYAMmsb SGKQLHlgIR36DUcTZn70APZdWWzO08WkOOiNk9xc6TcjcTncDAsXA6fJyvRYcbcV7KLP iYuA== X-Gm-Message-State: AKS2vOwQ+0kZkt2nSvKOZIpVRSc7FkIAcChK2Ac2OJRiyxklBzvaDQ0b YS9sz+k09vV3NpNsnNB1LUQCGlX+n3YIjqRDppXCDcsWtfXEjYNJlMSCTh8BkmLFWd3zLKsMQiC AxtpxzdE9xprsF8npqZkLCQ== X-Received: by 10.36.80.138 with SMTP id m132mr6331117itb.40.1498218895007; Fri, 23 Jun 2017 04:54:55 -0700 (PDT) X-Received: by 10.36.80.138 with SMTP id m132mr6331041itb.40.1498218893926; Fri, 23 Jun 2017 04:54:53 -0700 (PDT) Received: from [10.51.37.228] ([133.25.247.209]) by smtp.gmail.com with ESMTPSA id j62sm2907155iod.29.2017.06.23.04.54.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jun 2017 04:54:53 -0700 (PDT) Subject: Re: Inappropriate inner table for nested loop join From: Akihiko Odaki To: Albe Laurenz Cc: "pgsql-performance@postgresql.org" References: <6a997766-470e-393e-3605-e55d2b41d1a9@stu.hosei.ac.jp> <4b3fe214-6756-26d1-82d2-1882f7418033@stu.hosei.ac.jp> Message-ID: <81a17ec0-4556-8d41-e043-777433d8ba10@stu.hosei.ac.jp> Date: Fri, 23 Jun 2017 20:54:39 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <4b3fe214-6756-26d1-82d2-1882f7418033@stu.hosei.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 2017-06-23 20:20, Albe Laurenz wrote: > You could either try to do something like > > SELECT * > FROM (SELECT "posts".* > FROM "posts" > JOIN "follows" ON "follows"."target_account" = "posts"."account" > WHERE "follows"."owner_account" = $1 > OFFSET 0) q > ORDER BY "posts"."timestamp" > LIMIT 100; Now I wonder whether it actually sorted or not. As you said, I want to "find rows with the greatest 'timestamp', match with rows from 'posts' in a nested loop and stop as soon as it has found 100 matches". However, it seems to query 100 records without any consideration for "timestamp", and then sorts them. That is not expected. Here is a abstract query plan: Limit -> Sort Sort Key: posts.id DESC -> Nested Loop -> Seq Scan on follows Filter: (owner_account = $1) -> Index Scan using index_posts_on_account on posts Index Cond: (account_id = follows.target_account) index_posts_on_account is an obsolete index on "posts" and only for "account". So it does nothing for sorting "timestamp". Regards, Akihiko Odaki -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance