Am 27.08.2012 um 16:18 schrieb Tom Lane :
> Maximilian Tyrtania writes:
>
>> Sorry, should have mentioned that…Dropping and recreating it fixed it.
>
> Hm, had you changed the behavior of that function since creating the
> index?
To be honest - I don't know for sure. I might well have.
Maximi
Maximilian Tyrtania writes:
>> It might be a broken index issue. Please show the EXPLAIN for these queries.
> It was. I had an index like this:
> CREATE INDEX idx_firmen_iskunde_index
> ON firmen
> USING btree
> (f_firmen_iskunde(firmen.*));
> Sorry, should have mentioned thatÂ…Dropping and r
> On Mon, Aug 27, 2012 at 12:55 PM, Maximilian Tyrtania
> wrote:
>> What might be up there?
>
> It might be a broken index issue. Please show the EXPLAIN for these queries.
It was. I had an index like this:
CREATE INDEX idx_firmen_iskunde_index
ON firmen
USING btree
(f_firmen_iskunde(firm
On 08/27/2012 12:47 PM, Sergey Konoplev wrote:
On Mon, Aug 27, 2012 at 2:37 PM, Georges Racinet wrote:
I guess one must also reindex in case some record changes as well, right ?
Through a trigger maybe ?
You do not need to reindex it in case of record changes. The index
values will be recalcu
On Mon, Aug 27, 2012 at 2:37 PM, Georges Racinet wrote:
> I guess one must also reindex in case some record changes as well, right ?
> Through a trigger maybe ?
You do not need to reindex it in case of record changes. The index
values will be recalculated automatically after committing the
change
On 08/27/2012 12:14 PM, Sergey Konoplev wrote:
On Mon, Aug 27, 2012 at 1:56 PM, Maximilian Tyrtania
wrote:
It might be a broken index issue. Please show the EXPLAIN for these queries.
It was. I had an index like this:
CREATE INDEX idx_firmen_iskunde_index
ON firmen
USING btree
(f_firm
On Mon, Aug 27, 2012 at 1:56 PM, Maximilian Tyrtania
wrote:
>> It might be a broken index issue. Please show the EXPLAIN for these queries.
>
> It was. I had an index like this:
>
> CREATE INDEX idx_firmen_iskunde_index
> ON firmen
> USING btree
> (f_firmen_iskunde(firmen.*));
>
> Dropping and
> On Mon, Aug 27, 2012 at 12:55 PM, Maximilian Tyrtania
> wrote:
>> What might be up there?
>
> It might be a broken index issue. Please show the EXPLAIN for these queries.
It was. I had an index like this:
CREATE INDEX idx_firmen_iskunde_index
ON firmen
USING btree
(f_firmen_iskunde(firmen.
On Mon, Aug 27, 2012 at 12:55 PM, Maximilian Tyrtania
wrote:
> What might be up there?
It might be a broken index issue. Please show the EXPLAIN for these queries.
>
> Maximilian Tyrtania
> http://www.contactking.de
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
On Mon, 27 Aug 2012 10:55:43 +0200
Maximilian Tyrtania wrote:
> Hello from Berlin,
>
> I can't quite make sense of this (running PG 9.0.3):
>
> psql (9.0.3)
> Type "help" for help.
>
> FAKDB=# Select _rowid,f_firmen_isKunde(firmen),bezeichnung::text from
> firmen
> where
> (firmen.bezeichnung=
Hello from Berlin,
I can't quite make sense of this (running PG 9.0.3):
psql (9.0.3)
Type "help" for help.
FAKDB=# Select _rowid,f_firmen_isKunde(firmen),bezeichnung::text from firmen
where
(firmen.bezeichnung='Microsoft Deutsc
Let's say I have a table :
create table people (
person_id integer not null primary key,
firstnames varchar(50),
lastname varchar(50)
);
and another
create table partners (
first_person integer not null references people(person_id),
second_person integer not null reference people(person_id)
);
12 matches
Mail list logo
