Hello,
there were 3 hours in between the 2 queries. so I guess new data was loaded
already. new data is being loaded with that etl_run_id.
wkr,
Bert
On Mon, Feb 18, 2013 at 4:20 PM, Виктор Егоров wrote:
> 2013/2/18 Bert
>
>> When I don't touch the indexscan setting I
ting this value the seq scans were stopped,
and the better index_only scan / bitmap index scan were used for this
query.
Thank you Robe and Mabe_ for helping me with this issue!
wkr,
Bert
On Mon, Feb 18, 2013 at 2:42 PM, Bert wrote:
> Hello,
>
> yes, the tables are vacuumed every day
anything to do with the memory settings. Since it
already chooses this plan for the bigger partitions...
wkr,
Bert
On Mon, Feb 18, 2013 at 11:51 AM, Frank Lanitz wrote:
> Am 18.02.2013 10:43, schrieb Bert:
> > Does anyone has an idea what triggers this bad plan, and how I can fix
> it
s query planner, so only one of the partition needs to be used in
stead of 32.
How ever, we get some strange results. For some queries the runtime really
is a lot faster. But for the runtime is a even a bit longer.
Can anyone give me insight on why that can happen?
wkr,
Bert
y in this case the vacuum/analyze takes almost as
long on the parent table as on the biggest child table? (the other child
tables are smaller, and their vacuum/analyze time is much shorter).
wkr,
Bert
--
Bert Desmet
0477/305361
(SELECT ET.tick_server_id
FROM upsert b)
AND tra_id NOT IN
(SELECT ET.tra_id
FROM upsert b)
But I always get this error message:
ERROR: column "row1" is of type integer but expression is of type record
LINE 67: SELECT (ET.ROW1,
Does anyone has an idea?
wkr,
Bert
--
Bert Desmet
0477/305361
