Patrick Hatcher <[EMAIL PROTECTED]> writes:
> The following SQL takes 4+ mins to run. I have indexes on all join fields
> and I've tried rearranging the table orders but haven't had any luck.
Please show EXPLAIN ANALYZE output, not just EXPLAIN. It's impossible
to tell whether the planner is mak
On Thu, Jan 05, 2006 at 06:50:22PM -0800, David Lang wrote:
> On Thu, 5 Jan 2006, Mark Liberman wrote:
>
> >Obviously, I will be testing this - but it might take a few days, as I
> >haven't
> >figure out how to simulate the "period of inactivity" to get the data
> >flushed
> >out of the cache ..
"Mark Liberman" <[EMAIL PROTECTED]> wrote
>
> Now, my follow-up question / assumption. I am assuming that the IO time
> is
> so long on that index because it has to read the entire index (for that
> file_id) into memory
>
> any confirmation / corrections to my assumptions are greatly appreciate
On Thu, 5 Jan 2006, Mark Liberman wrote:
Obviously, I will be testing this - but it might take a few days, as I haven't
figure out how to simulate the "period of inactivity" to get the data flushed
out of the cache ... so I have to run this each morning.
cat large_file >/dev/null
will probabl
On Thursday 05 January 2006 15:12, Qingqing Zhou wrote:
> "Mark Liberman" <[EMAIL PROTECTED]> wrote
>
> > First run, after a night of inactivity:
> >
> > -> Bitmap Index Scan on
> > 1min_events_file_id_begin_idx (cost=0.00..37.85 rows=3670 width=0)
> > (actual time=313.468..313
On Wed, Jan 04, 2006 at 11:00:38AM -0500, Ian Westmacott wrote:
> The WAL is a 2-spindle (SATA) RAID0 with its own controller (ext3).
> The tables are on a 10-spindle (SCSI) RAID50 with dual U320
> controllers (XFS). This is overkill for writing and querying the data,
> but we need to constantly A
Pg: 7.4.9
RH: ES v3
Quad-Xeon
16G ram
The following SQL takes 4+ mins to run. I have indexes on all join fields
and I've tried rearranging the table orders but haven't had any luck. I
have done the usual vacuums analyze and even vacuum FULL just to make sure
but still the same results. The endi
"Mark Liberman" <[EMAIL PROTECTED]> wrote
>
> First run, after a night of inactivity:
>
> -> Bitmap Index Scan on 1min_events_file_id_begin_idx
> (cost=0.00..37.85 rows=3670 width=0) (actual time=313.468..313.468
> rows=11082
> loops=1)
> Index Cond:
On Thu, 5 Jan 2006 17:16:47 +0200
"Andy" <[EMAIL PROTECTED]> wrote:
> Hi to all,
>
> I have the following query:
>
> SELECT count(*) FROM orders o
> INNER JOIN report r ON r.id_order=o.id
> WHERE o.id_status>3
> How can I improve this query's performace?? The ideea is to count all
Hi, William,
William Yu wrote:
> Random write performance (small block that only writes to 1 drive):
> 1 write requires N-1 reads + N writes --> 1/2N-1 %
This is not true. Most Raid-5 engines use XOR or similar checksum
methods. As opposed to cryptographic checksums, those can be updated and
cor
Hi to all,
I have the following query:
SELECT count(*) FROM orders
o INNER JOIN report r ON
r.id_order=o.id WHERE
o.id_status>3
Explaing analyze:
Aggregate (cost=8941.82..8941.82 rows=1
width=0) (actual time=1003.297..1003.298 rows=1 loops=1) ->
Hash Join (cost=3946.28.
Hi, Jeffrey,
Jeffrey W. Baker wrote:
> A few WEEKS ago, the autovacuum on my instance of pg 7.4 unilaterally
> decided to VACUUM a table which has not been updated in over a year and
> is more than one terabyte on the disk.
Hmm, maybe this is the Transaction ID wraparound emerging, and VACUUM is
12 matches
Mail list logo
