On Sat, Jan 17, 2015 at 02:03:34PM +0100, Andreas Kretschmer wrote:
Peter Hicks peter.hi...@poggs.co.uk wrote:
All,
I have a Rails application on 9.3 in which I want to enforce a unique
index on a set of fields, one of which includes a NULL-able column.
According to
All,
I have a Rails application on 9.3 in which I want to enforce a unique
index on a set of fields, one of which includes a NULL-able column.
According to
http://www.postgresql.org/docs/9.3/static/indexes-unique.html, btree
indexes can't handle uniqueness on NULL columns, so I'm looking
On Sat, Jan 17, 2015 at 6:27 AM, Peter Hicks peter.hi...@poggs.co.uk
wrote:
All,
I have a Rails application on 9.3 in which I want to enforce a unique
index on a set of fields, one of which includes a NULL-able column.
According to
Hi John
On 17/01/15 12:39, John McKown wrote:
I read the above. As I understand it, you can have a unique index on
a column which is NULL-able. That will guarantee that all the non-NULL
values are unique. What it will not guarantee is that there will be at
most one NULL value in the indexed
Peter Hicks peter.hi...@poggs.co.uk wrote:
All,
I have a Rails application on 9.3 in which I want to enforce a unique
index on a set of fields, one of which includes a NULL-able column.
According to
http://www.postgresql.org/docs/9.3/static/indexes-unique.html, btree
indexes can't
In a query plan, I noticed the following:
Join Filter: (((all_permissions.role_recursive AND (alternatives:
SubPlan 5 or hashed SubPlan 6)) OR (permitted_e.id = deployed_e.id)) AND (NOT
(SubPlan 13)))
What's the 'alternatives' line? Brand new to me!
--
-- Christophe Pettus
Hi Christophe,
On 2012-11-28 13:07:12 -0800, Christophe Pettus wrote:
In a query plan, I noticed the following:
Join Filter: (((all_permissions.role_recursive AND
(alternatives: SubPlan 5 or hashed SubPlan 6)) OR
(permitted_e.id = deployed_e.id)) AND (NOT (SubPlan
Hi, Andres,
Thanks!
On Nov 28, 2012, at 1:58 PM, Andres Freund wrote:
http://www.postgresql.org/docs/current/interactive/release-9-2.html#AEN110503
Does that apply to views as well? (This particular plan was not from a
prepared or PL/pgSQL statement, but did include views.)
--
--
Hi,
On 2012-11-28 14:16:18 -0800, Christophe Pettus wrote:
Thanks!
Not much to thank for, the answer was actually wrong...
Does that apply to views as well? (This particular plan was not from a
prepared or PL/pgSQL statement, but did include views.)
Its not really relevant for views no.
Andres Freund and...@anarazel.de writes:
The commit introducing this is:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=bd3daddaf232d95b0c9ba6f99b0170a0147dd8af
What that does to add hashing support for IN(). But hashing can be
pessimal in comparison to a explicit check if
On Wed, Aug 22, 2012 at 05:56:27PM -0700, Jeff Janes wrote:
It's wide-ish, too, 98 columns.
How many of the columns are NULL for any given row? Or perhaps
better, what is the distribution of values for any given column? For
a given column, is there some magic value (NULL, 0, 1, -1, ,
On Thu, Aug 16, 2012 at 1:54 PM, Wells Oliver wellsoli...@gmail.com wrote:
Hey folks, a question. We have a table that's getting large (6 million rows
right now, but hey, no end in sight).
Does it grow in chunks, or one row at a time?
It's wide-ish, too, 98 columns.
How many of the columns
On Thu, Aug 16, 2012 at 2:54 PM, Wells Oliver wellsoli...@gmail.com wrote:
Hey folks, a question. We have a table that's getting large (6 million rows
right now, but hey, no end in sight). It's wide-ish, too, 98 columns.
The problem is that each of these columns needs to be searchable quickly
Hey folks, a question. We have a table that's getting large (6 million rows
right now, but hey, no end in sight). It's wide-ish, too, 98 columns.
The problem is that each of these columns needs to be searchable quickly at
an application level, and I'm far too responsible an individual to put 98
On Thu, Aug 16, 2012 at 3:54 PM, Wells Oliver wellsoli...@gmail.com wrote:
Hey folks, a question. We have a table that's getting large (6 million rows
right now, but hey, no end in sight). It's wide-ish, too, 98 columns.
The problem is that each of these columns needs to be searchable quickly
15 matches
Mail list logo
