Heikki Linnakangas writes:
> We should do this automatically. Or am I missing something?
Yes. This is not equality.
> ALTER OPERATOR FAMILY integer_ops USING btree ADD
> OPERATOR 3 <@ (int4, int4range),
> FUNCTION 1 btint4rangecmp(int4, int4range);
That will break approximately everything
> We should do this automatically. Or am I missing something?
Aside from the need to support @> as well, not that I can see.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subsc
On 22.03.2013 02:05, Josh Berkus wrote:
Well, no.<@ is not a btree-indexable operator.
Yes, but it's equivalent to ( ( a>= b1 or b1 is null ) and ( a< b2 or
b2 is null ) ), which *is* btree-indexable and can use an index. So it
seems like the kind of optimization we could eventually make.
Y
I changed the name of the table for the post but forgot to change it in the
results of the explain. Table1 is busbase.
On Fri, Mar 22, 2013 at 6:25 PM, Misa Simic wrote:
> Hi,
>
> there is something mixed..
>
> your index is on table1
>
> Explain Analyze reports about table called: busbase.
Hi,
there is something mixed..
your index is on table1
Explain Analyze reports about table called: busbase
Kind Regards,
Misa
2013/3/22 Cindy Makarowsky
> But, I do have an index on Table1 on the state field which is in my group
> by condition:
>
> CREATE INDEX statidx2
> ON ta
But, I do have an index on Table1 on the state field which is in my group
by condition:
CREATE INDEX statidx2
ON table1
USING btree
(state COLLATE pg_catalog."default" );
I have vacuumed the table too.
On Fri, Mar 22, 2013 at 5:13 PM, Josh Berkus wrote:
> On 03/22/2013 12:46 PM, Cindy Mak
On 21.03.2013 17:55, Alexander Korotkov wrote:
On Thu, Mar 21, 2013 at 12:52 PM, Heikki Linnakangas<
The immediate fix is attached, but this made me realize that rangesel() is
still missing estimation for the "element<@ range" operator. It shouldn't
be hard to implement, I'm pretty sure we have
On 03/22/2013 12:46 PM, Cindy Makarowsky wrote:
> I've tried playing around with the settings in the config file for
> shared_buffers, work_mem, etc restarting Postgres each time and nothing
> seems to help.
Well, you're summarizing 55 million rows on an unindexed table:
"-> Seq Scan on
I have two tables in Postgres 9.2 on a Linux server with 8GB of RAM. The
first table has 60 million records:
CREATE TABLE table1
(
id integer,
update date,
company character(35),
address character(35),
city character(20),
state character(2),
zip character(9),
phone character(10),
