Maciek Sakrejda wrote:
> Before the switch, everything was running fine.
One thing to look for is a connection stuck in "idle in transaction"
or old prepared transactions in pg_prepared_xacts. Either will cause
all sorts of problems, but if you are using serializable transactions
the error you ar
On 10/24/2012 02:31 PM, Shaun Thomas wrote:
The main flaw with my example is that it's random. But I swear I'm not
making it up! :)
And then I find a way to make it non-random. Hooray:
CREATE TABLE date_test (
id SERIAL,
col1 varchar,
col2 numeric,
action_date TIMESTAMP WITHOUT TIME Z
On 10/24/2012 02:11 PM, Tom Lane wrote:
It's not particularly (not that you've even defined what you think
"optimistic" is, much less mentioned what baseline you're comparing
to).
The main flaw with my example is that it's random. But I swear I'm not
making it up! :)
There seems to be a par
Shaun Thomas writes:
> 1. Is there any way to specifically set stats on a functional index?
Sure, the same way you would for a table.
regression=# create table foo (f1 int, f2 int);
CREATE TABLE
regression=# create index fooi on foo ((f1 + f2));
CREATE INDEX
regression=# \d fooi
Index "pub
Hi Jeff,
thanks for your answer!
Am 24.10.2012 um 19:00 schrieb Jeff Janes:
> On Wed, Oct 24, 2012 at 8:41 AM, Böckler Andreas wrote:
>
>> SELECT m.machine_id, s.timestamp, s.errorcode
>> FROM events m INNER JOIN spsdata as s ON (m.machine_id= s.machine_id
>
> m.machine_id is equal to itself
Hey everyone,
So recently we upgraded to 9.1 and have noticed a ton of our queries got
much worse. It turns out that 9.1 is *way* more optimistic about our
functional indexes, even when they're entirely the wrong path. So after
going through the docs, I see that the normal way to increase stat
Hi,
i've got a very strange problem on PostgreSQL 8.4, where the queryplaner goes
absolutely havoc, when slightly changing one parameter.
First the Tables which are involved:
1.Table "public.spsdata"
Column|Type
