On Tue, Nov 28, 2017 at 10:55 PM, Emanuel Alvarez
wrote:
> hi all,
>
> we're in the process of optimizing some queries and we've noted a case
> where the planner prefers a sequential scan instead of using an index,
> while the index scan is actually much faster. to give you some
> context: we hav
Thank you all for your responses!
On Wed, Nov 29, 2017 at 7:31 AM, legrand legrand
wrote:
> Hi,
>
> Could you give us the partitions (ranges values) and indexes definition for
> result table ?
We partition by month, they usually start the 20th of each month (this
was the date we partitioned the
Andres Freund wrote:
> On 2017-11-29 18:17:18 +0100, Laurenz Albe wrote:
> > That is because the execution with the sequential scan touched
> > 26492 + 80492 = 106984 blocks, while the second execution touched
> > 311301 + 48510 = 359811 blocks, more than three times as many.
>
> That's not neces
On 2017-11-29 18:17:18 +0100, Laurenz Albe wrote:
> That is because the execution with the sequential scan touched
> 26492 + 80492 = 106984 blocks, while the second execution touched
> 311301 + 48510 = 359811 blocks, more than three times as many.
That's not necessarily said. What those count are
Emanuel Alvarez wrote:
> the problematic query looks like this:
>
> SELECT keywords.strategy_id, results.position, results.created_at FROM results
> JOIN keywords ON results.keyword_id = keywords.id
> WHERE results.account_id = 1
> AND results.created_at >= '2017-10-25 00:00:00.00'
>
Hi
On Wed, Nov 29, 2017 at 8:55 AM, Emanuel Alvarez
wrote:
> on the other hand, if we disable sequential scans (SET enable_seqscan
> = 0), we see than not only the query runs faster but the cost seems to
> be lower, as seen in the query plan [2].
True, the cost of the scan itself is lower, but
Hi,
Could you give us the partitions (ranges values) and indexes definition for
result table ?
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
