On 11/05/13 01:30, Tom Lane wrote:
Mark Kirkwood writes:
Unfortunately a trigger will not really do the job - analyze ignores in
progress rows (unless they were added by the current transaction), and
then the changes made by analyze are not seen by any other sessions. So
no changes to plans unt
On Friday, May 10, 2013, Robert Haas wrote:
> On Sat, Mar 23, 2013 at 8:12 PM, Misa Simic
> >
> wrote:
> > but problem is - we don't know the thing id - we know calc_id:
> >
> > EXPLAIN ANALYZE
> > SELECT * FROM t2_left_t3_volatile v INNER JOIN t1 USING (thing_id)
> > WHERE calc_id = 20
>
> With
On Sat, Mar 23, 2013 at 8:12 PM, Misa Simic wrote:
> but problem is - we don't know the thing id - we know calc_id:
>
> EXPLAIN ANALYZE
> SELECT * FROM t2_left_t3_volatile v INNER JOIN t1 USING (thing_id)
> WHERE calc_id = 20
With this query you've got to scan all three tables. The calc_id qual
Mark Kirkwood writes:
> Unfortunately a trigger will not really do the job - analyze ignores in
> progress rows (unless they were added by the current transaction), and
> then the changes made by analyze are not seen by any other sessions. So
> no changes to plans until the entire INSERT is com
(See below for the reply)
On 10/05/13 22:48, Vitalii Tymchyshyn wrote:
Well, could you write a trigger that would do what you need? AFAIR
analyze data is stored no matter transaction boundaries. You could store
some counters in session vars and issue an explicit analyze when enough
rows were add
Well, could you write a trigger that would do what you need? AFAIR analyze
data is stored no matter transaction boundaries. You could store some
counters in session vars and issue an explicit analyze when enough rows
were added.
7 трав. 2013 08:33, "Mark Kirkwood" напис.
> On 07/05/13 18:10, Simo
