Jeff Janes:
That is such a beautiful little trick. I made a table with just ids, and a
query for it reads almost 10 times less buffers (as reported by explain
analyze buffers), and sure enough, after another reboot, query executes
about 10 times faster.
I'm not doing anything special with those r
On Mon, Nov 2, 2015 at 12:19 AM, Andrey Osenenko
wrote:
>
> It also looks like if there was a way to create a table with just primary
> key and add an index to it that indexes data from another table, it would
> work much, much faster since there would be very little to read from disk
> after inde
On 11/2/15 2:19 AM, Andrey Osenenko wrote:
It also looks like if there was a way to create a table with just
primary key and add an index to it that indexes data from another table,
it would work much, much faster since there would be very little to read
from disk after index lookup. But looks li
Thank you.
That's really sad news. This means that even though there is an index that
lets you find rows you want almost immediately, to retrieve primary keys,
you still have to do a lot of disk io.
I created a new table that contains only primary key and tsvector value,
and (at least that's how
On Sun, Nov 1, 2015 at 10:52 PM, Andrey Osenenko
wrote:
> I have a table with roughly 300 000 rows, each row containing two large
> strings - one is news article HTML, the other is news article plaintext. The
> table has a bigint primary key.
>
> A GIN index is used to do fulltext search on the pl
I have a table with roughly 300 000 rows, each row containing two large
strings - one is news article HTML, the other is news article plaintext.
The table has a bigint primary key.
A GIN index is used to do fulltext search on the plaintext part. All I want
to retrieve when I do fulltext search is
