On Fri, Dec 15, 2006 at 02:29:48PM +0530, Gurjeet Singh wrote:
> Is it session level !!??? I think it is query level; don't we discard the
> plan after each query? AFAIK, only the plpgsql and other pl/ sisters cache
> the plan for the queries inside their code-blocks. I am under the impression
> th
On 12/14/06, Martijn van Oosterhout wrote:
On Thu, Dec 14, 2006 at 09:35:47AM -0800, Ben wrote:
> Interesting. Is that plan cached for the life of the session doing the
> inserts, the life of the trigger, or until the database is restarted?
Duration of a session, there is no support to cache a
OK, thanks.
On Thu, 14 Dec 2006, Martijn van Oosterhout wrote:
On Thu, Dec 14, 2006 at 09:35:47AM -0800, Ben wrote:
Interesting. Is that plan cached for the life of the session doing the
inserts, the life of the trigger, or until the database is restarted?
Duration of a session, there is no
On Thu, Dec 14, 2006 at 09:35:47AM -0800, Ben wrote:
> Interesting. Is that plan cached for the life of the session doing the
> inserts, the life of the trigger, or until the database is restarted?
Duration of a session, there is no support to cache a plan for any other
period.
> I guess I'm try
Interesting. Is that plan cached for the life of the session doing the
inserts, the life of the trigger, or until the database is restarted?
I guess I'm trying to figure out how to get the plan to re-cache, without
making it entirely dynamic.
On Thu, 14 Dec 2006, Richard Huxton wrote:
Ben w
Ben wrote:
When you insert a tuple, it needs to be inserted into the index, yes.
There
is no way an insert can cause a sequential scan, except by some trigger
defined on the table.
Actually, as it happens, there *is* a trigger defined on the table to
fire before insert, but it too uses an ind
Ben <[EMAIL PROTECTED]> writes:
> Wouldn't it need to check the unique constraint (an index on the table)
> before the insert can succeed? It seems like it would be better to check
> the index than to do a full table scan to try to satisfy that constraint.
Postgres contains no code that would ev
When you insert a tuple, it needs to be inserted into the index, yes. There
is no way an insert can cause a sequential scan, except by some trigger
defined on the table.
Actually, as it happens, there *is* a trigger defined on the table to fire
before insert, but it too uses an index scan, at l
On Wed, Dec 13, 2006 at 02:01:46PM -0800, Ben wrote:
>
>
> On Wed, 13 Dec 2006, Martijn van Oosterhout wrote:
>
> >>- 7.3 isn't smart enough to use an index on an insert? Seems unlikely.
> >
> >This question makes no sense, you don't need an index to insert.
>
> Wouldn't it need to check the un
On Wed, 13 Dec 2006, Martijn van Oosterhout wrote:
- 7.3 isn't smart enough to use an index on an insert? Seems unlikely.
This question makes no sense, you don't need an index to insert.
Wouldn't it need to check the unique constraint (an index on the table)
before the insert can succeed?
On Wed, Dec 13, 2006 at 01:10:44PM -0800, Ben wrote:
> I'm using an ancient version of postgresql (7.3 - don't ask) and I'm
> experiencing a problem where many inserts into an empty table slow down
> over time, even if I analyze in the middle of the insertions.
> pg_stat_user_tables shows lots a
11 matches
Mail list logo
