From: | Bill Moran <wmoran(at)potentialtech(dot)com> |
---|---|
To: | Robert James <srobertjames(at)gmail(dot)com> |
Cc: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>, Thomas Kellerer <spam_eater(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Work table |
Date: | 2013-10-29 03:45:46 |
Message-ID: | 20131028234546.05c8efa8695e30a9556c50b9@potentialtech.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 28 Oct 2013 15:50:42 -0400 Robert James <srobertjames(at)gmail(dot)com> wrote:
> It could be > 1 Million rows.
>
> SELECT is:
>
> SELECT *
> FROM another_table
> WHERE
> eventtime > (SELECT e FROM tags WHERE id = $1) AND
> eventtime < (SELECT e FROM tags WHERE id = $2)
> ;
>
> $1 and $2 are integers.
>
> SELECT ran just now, returning >1Million rows, in 1.6 seconds.
>
> Inserting into work table causes weird behavior - it takes over a
> minute, PG CPU climbs to 100%, but then other subsequent queries
> sometimes seem to slow down too. After a lot of these, sometimes PG
> acts irresponsive until I restart it.
Depending on the nature of your hardware, this might not be weird ...
For example, if you have enough RAM that all of another_table fits
in RAM, and (comparitively) slow disks, the SELECT would run
considerably faster than an insert of the same size.
--
Bill Moran <wmoran(at)potentialtech(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Matt | 2013-10-29 06:16:43 | INSERT/UPDATE statements sometimes choosing not to use PK index? |
Previous Message | Adrian Klaver | 2013-10-28 23:50:10 | Re: Cursor Example Needed |