Josh,
You're absolutely correct that the overhead becomes less significant as the
partitioning prunes more rows. I can even see a two-partition table being
useful in some situations (e.g., a table divided into a relatively small
"recent data" partition and a much larger "historical data" partitio
Hi all,
Can someone please help me optimize this query? Is there a better way to write this query? I am generating a report of transactions ordered by time and with details of the sender and receiver etc.
SELECT distinct a.time::date ||''||substring(a.time::time::text,1,8) as Time,CASE WHEN a.
On Tue, 2004-12-14 at 17:36, Rod Taylor wrote:
> Are there any tricks to speeding up pg_dump aside from doing them from a
> replicated machine?
>
> I'm using -Fc with no compression.
Run a separate pg_dump for larger tables and run them concurrently so
you use more cpu and disk resources.
The lo
Sven Willenberger <[EMAIL PROTECTED]> writes:
> On a related note, is there a way (other than set enable_seqscan=off) to
> give a hint to the planner that it is cheaper to use and index scan
> versus seq scan?
There are basically two things you can do. One: if the planner's
rowcount estimates are
On Mon, 2004-12-13 at 17:43 -0500, Tom Lane wrote:
> Sven Willenberger <[EMAIL PROTECTED]> writes:
> > explain analyze select storelocation,order_number from custacct where
> > referrer = 1365 and orderdate between '2004-12-07' and '2004-12-07
> > 12:00:00' order by custacctid limit 10;
>
> >
Hi, Christopher,
[sorry for the delay of my answer, we were rather busy last weks]
On Thu, 04 Nov 2004 21:29:04 -0500
Christopher Browne <[EMAIL PROTECTED]> wrote:
> In an attempt to throw the authorities off his trail, [EMAIL PROTECTED]
> (Markus Schaber) transmitted:
> > We should create a lis
Are there any tricks to speeding up pg_dump aside from doing them from a
replicated machine?
I'm using -Fc with no compression.
--
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomai
Joshua D. Drake wrote:
An Opteron, properly tuned with PostgreSQL will always beat a Xeon
in terms of raw cpu.
RAID 10 will typically always outperform RAID 5 with the same HD config.
Fibre channel in general will always beat a normal (especially an LSI)
raid.
Dell's suck for PostgreSQL.
Does any
