On Wed, Nov 23, 2016 at 4:19 PM, Thomas Munro
wrote:
> On Wed, Oct 12, 2016 at 4:19 PM, Thomas Munro
> wrote:
>> Here it is, now split into two parts: one patch
>> to add an amskip operation, and another to consider using it to
>> implement DISTINCT when it was already has an index only scan path
On 23 November 2016 at 21:19, Thomas Munro
wrote:
> Worth pursuing? Does amskip suck? Does anyone have better ideas,
> either for how to do the low level skip or the higher level Index Skip
> Scan, or perhaps a completely different way of looking at this?
I have no helpful suggestions with how
On Wed, Oct 12, 2016 at 4:19 PM, Thomas Munro
wrote:
> Here it is, now split into two parts: one patch
> to add an amskip operation, and another to consider using it to
> implement DISTINCT when it was already has an index only scan path on
> an index that supports skipping.
Those patches add an
On Sat, Nov 1, 2014 at 10:35 AM, Thomas Munro wrote:
> I am definitely interested in collaborating on a series of patches to
> implement various kinds of skip-based plans as seen in other RDBMSs if
> others think it could be useful. I see skip-based DISTINCT as a good
> place to start. (I suspec
On 27 October 2014 20:24, David Rowley wrote:
> I've had a quick look at this and it seems like a great win! I'm quite
> surprised that we've not got this already. I think this technology could
> also really help performance of queries such as SELECT * from bigtable bt
> WHERE EXISTS(SELECT 1 FROM
On Sat, Jul 5, 2014 at 12:17 PM, Thomas Munro wrote:
> postgres=# set enable_hashagg = false;
> SET
> Time: 0.302 ms
> postgres=# explain select distinct a from foo;
>
> ┌─┐
> │
On 5 July 2014 02:03, Vik Fearing wrote:
> [1] http://wiki.postgresql.org/wiki/Loose_indexscan
Thanks. It talks about DISTINCT, and also about using index when you
don't have the leading column in your WHERE clause (as well as MySQL
("loose"), at least Oracle ("skip"), SQLite ("skip"), DB2 ("jump
On 07/05/2014 02:17 AM, Thomas Munro wrote:
> As an exercise I hacked up the simplest code I could think of that would
> demonstrate a faster DISTINCT based on skipping ahead to the next
> distinct value in an index-only scan. Please see the attached (extremely
> buggy) patch, and the example sessi
Hello
As an exercise I hacked up the simplest code I could think of that would
demonstrate a faster DISTINCT based on skipping ahead to the next distinct
value in an index-only scan. Please see the attached (extremely buggy)
patch, and the example session below. (It's against my natural instinct
