On Sat, 2005-12-17 at 21:10 -0800, James Klo wrote:
> I need to routinely move data from the timeblock table to an archive
> table with the same schema named timeblock_archive. I really need this
> to happen as quickly as possible, as the archive operation appears to
> really tax the db server.
On Thu, 2005-12-15 at 18:23 -0800, Craig A. James wrote:
> So, "you still have no problem" is exactly wrong, because Postgres picked the
> wrong plan. Postgres decided that applying myfunc() to 10,000,000 rows was a
> better plan than an index scan of 50,000 row_nums. So I'm screwed.
FWIW,
The
On Thu, 2005-12-15 at 01:48 -0600, Kevin Brown wrote:
> > Well, I'm no expert either, but if there was an index on
> > ordered_products (paid, suspended_sub, id) it should be mergejoinable
> > with the index on to_ship.ordered_product_id, right? Given the
> > conditions on paid and suspended_sub.
On Fri, 2005-12-02 at 23:03 -0500, Luke Lonergan wrote:
> And how do we compose the binary data on the client? Do we trust that the
> client encoding conversion logic is identical to the backend's?
Well, my newbieness is undoubtedly showing already, so I might as well
continue with my line of du
On Fri, 2005-12-02 at 13:24 -0800, Luke Lonergan wrote:
> It's a matter of safety and generality - in general you
> can't be sure that client machines / OS'es will render the same conversions
> that the backend does in all cases IMO.
Can't binary values can safely be sent cross-platform in DataRow
On Fri, 2005-11-11 at 09:17 -0500, Tom Lane wrote:
> Richard Huxton writes:
> > Does external_id_map really have 15 million rows? If not, try a VACUUM
> > FULL on it. Be prepared to give it some time to complete.
>
> Please don't, actually, until we understand what's going on.
Ack, I was the mi
On Fri, 2005-11-11 at 11:51 +, Richard Huxton wrote:
> Does external_id_map really have 15 million rows? If not, try a VACUUM
> FULL on it. Be prepared to give it some time to complete.
Thanks for the reply. It does indeed have that many rows:
statgen=> select count(*) from util.external_id_
On Thu, 2005-11-10 at 12:23 -0500, Tom Lane wrote:
> Apparently, you are using a platform and/or locale in which strcoll() is
> spectacularly, god-awfully slow --- on the order of 10 msec per comparison.
The version with the condition is definitely doing more I/O. The
version without the conditio
This is with Postgres 8.0.3. Any advice is appreciated. I'm not sure
exactly what I expect, but I was hoping that if it used the
external_id_map_source_target_id index it would be faster. Mainly I was
surprised that the same plan could perform so much differently with just
an extra condition.
I
