On Tue, Dec 5, 2017 at 10:50 AM, Tom Lane wrote:
> Jeff Janes writes:
> > On Dec 3, 2017 15:31, "Tom Lane" wrote:
> >> Jeff Janes writes:
> >>> But I do see that ties within the logical order of the column values
> are
> >>> broken to agree with the physical order. That is wrong, right? Is
>
On Sun, Dec 3, 2017 at 1:15 PM, Vitaliy Garnashevich <
vgarnashev...@gmail.com> wrote:
> On 02/12/2017 23:17, Jeff Janes wrote:
>
> Right, so there is a cpu costing problem (which could only be fixed by
> hacking postgresql and recompiling it), but it is much smaller of a problem
> than the IO cos
> On Dec 5, 2017, at 11:23 PM, Sergei Kornilov wrote:
> You has very slow (or busy) disks, not postgresql issue. Reading 6760 * 8KB
> in 70 seconds is very bad result.
>
> For better performance you need better disks, at least raid10 (not raid5).
> Much more memory in shared_buffers can help w
What seems odd to me is that in different kinds of tests (with
different frequency of column values):
i1 Rows Removed by Filter = 900156, 179792, 89762 (decreased a lot)
i1 buffers = 46983, 44373, 39928 (decreased, but not a lot)
i1 best case time = 756.045, 127.814, 79.492 (decreased a lot, a
On Tue, Dec 05, 2017 at 01:50:11PM -0500, Tom Lane wrote:
> Jeff Janes writes:
> > On Dec 3, 2017 15:31, "Tom Lane" wrote:
> >> Jeff Janes writes:
> >>> But I do see that ties within the logical order of the column values are
> >>> broken to agree with the physical order. That is wrong, right?
Alex Reece wrote:
> I get very different plan chosen when my query is in a lateral subquery vs
> standalone --
> it doesn't use a key when joining on a table, instead opting to do a hash
> join. Here is the query:
>
> select distinct on (sub.entity_id, sub.note_id, sub.series_id)
>
