On Sat, Jan 17, 2015 at 02:03:34PM +0100, Andreas Kretschmer wrote:
> Peter Hicks 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.postgre
Peter Hicks 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 handle uniqueness
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 c
On Sat, Jan 17, 2015 at 6:27 AM, Peter Hicks
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 indexe
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 for
Andres Freund 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 only a few value
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.
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.)
--
-- Christoph
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 (Sub
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
x...@th
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, 9
On Thu, Aug 16, 2012 at 2:54 PM, Wells Oliver 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 at
> an applicatio
On Thu, Aug 16, 2012 at 1:54 PM, Wells Oliver 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 are NULL for any giv
On Thu, Aug 16, 2012 at 3:54 PM, Wells Oliver 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 at
> an applicatio
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
in
15 matches
Mail list logo
