Thread: [PATCH] indexability of << operator for inet/cidr
Attached is a patch that explains to optimizer that its possible to use index when performing a << b where a is an inet/cidr value and b is a constant. Indexpath generated for such an expression is this: (a > network(b)) and (a <= set_masklen(broadcast(b, 32))) Since this is my first time delving in the guts of postgres, someone definitely should review it :) I mostly based my code on prefix_quals function for string types. Thanks
Alex Pilosov <alex@pilosoft.com> writes:
> Indexpath generated for such an expression is this:
> (a > network(b)) and (a <= set_masklen(broadcast(b, 32)))
What happens to that set_masklen thing for IPv6?
If the network.c code were exporting a function that made this value,
I'd not worry; but I don't like wiring an IPv4 assumption into code far
away in the planner. Can't we do better here? Perhaps move the
generation of the indexscan bound values into a subroutine in network.c?
regards, tom lane
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. > Attached is a patch that explains to optimizer that its possible to use > index when performing a << b where a is an inet/cidr value and b is a > constant. > > Indexpath generated for such an expression is this: > (a > network(b)) and (a <= set_masklen(broadcast(b, 32))) > > Since this is my first time delving in the guts of postgres, someone > definitely should review it :) > > I mostly based my code on prefix_quals function for string types. > > Thanks > Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Thu, 14 Jun 2001, Tom Lane wrote: > Alex Pilosov <alex@pilosoft.com> writes: > > Indexpath generated for such an expression is this: > > (a > network(b)) and (a <= set_masklen(broadcast(b, 32))) > > What happens to that set_masklen thing for IPv6? > > If the network.c code were exporting a function that made this value, > I'd not worry; but I don't like wiring an IPv4 assumption into code far > away in the planner. Can't we do better here? Perhaps move the > generation of the indexscan bound values into a subroutine in network.c? Good point. I already rewrote it, but I am going to send it in tomorrow, I want to resync to HEAD, since some of network.c was taken in and I want to have a clean patch for you guys :) Thanks -alex
Patch removed from queue, awaiting updated version. > Attached is a patch that explains to optimizer that its possible to use > index when performing a << b where a is an inet/cidr value and b is a > constant. > > Indexpath generated for such an expression is this: > (a > network(b)) and (a <= set_masklen(broadcast(b, 32))) > > Since this is my first time delving in the guts of postgres, someone > definitely should review it :) > > I mostly based my code on prefix_quals function for string types. > > Thanks > Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026