With hardware tuning, I am sure we can do better than 35Mb per sec. Also
WTF ?
My Laptop does 19 MB/s (reading <10 KB files, reiser4) !
A recent desktop 7200rpm IDE drive
# hdparm -t /dev/hdc1
/dev/hdc1:
Timing buffered disk reads: 148 MB in 3.02 seconds = 49.01 MB/sec
# ll
On Tue, 2005-03-29 at 01:48 -0700, Karim A Nassar wrote:
> > Each value has 1/13th of the table, which is too many rows per value to
> > make an IndexScan an efficient way of deleting rows from the table.
>
> But, the original question was that the delete that was taking a long time
> was on a dif
Yeah, 35Mb per sec is slow for a raid controller, the 3ware mirrored is
about 50Mb/sec, and striped is about 100
Dave
PFC wrote:
With hardware tuning, I am sure we can do better than 35Mb per sec. Also
WTF ?
My Laptop does 19 MB/s (reading <10 KB files, reiser4) !
A recent desktop 720
On Tue, 29 Mar 2005, Simon Riggs wrote:
> On Tue, 2005-03-29 at 01:48 -0700, Karim A Nassar wrote:
> > > Each value has 1/13th of the table, which is too many rows per value to
> > > make an IndexScan an efficient way of deleting rows from the table.
> >
> > But, the original question was that the
On Tue, 29 Mar 2005, Stephan Szabo wrote:
> On Tue, 29 Mar 2005, Simon Riggs wrote:
>
> > On Tue, 2005-03-29 at 01:48 -0700, Karim A Nassar wrote:
> > > > Each value has 1/13th of the table, which is too many rows per value to
> > > > make an IndexScan an efficient way of deleting rows from the ta
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 29 Mar 2005, Simon Riggs wrote:
>> The SQL generated for RI checking by the RI triggers currently applies a
>> limit at execution time, not at prepare time. i.e. there is no LIMIT
>> clause in the SQL.
>>
>> We know whether the check will be limi
Simon Riggs <[EMAIL PROTECTED]> writes:
> ...but, I see no way for OidFunctionCall8 to ever return an answer of
> "always just 1 row, no matter how big the relation"...so tuples_fetched
> is always proportional to the size of the relation. Are unique indexes
> treated just as very-low-selectivity i
On Mon, 2005-03-28 at 17:36 +, Steve Poe wrote:
> I agree with you. Unfortunately, I am not the developer of the
> application. The vendor uses ProIV which connects via ODBC. The vendor
> could certain do some tuning and create more indexes where applicable. I
> am encouraging the vendor t
Stephan Szabo <[EMAIL PROTECTED]> writes:
> If there were some way to pass a "limit" into SPI_prepare that was treated
> similarly to a LIMIT clause for planning purposes but didn't actually
> change the output plan to only return that number of rows, we could use
> that.
Hmm ... the planner does
On Tue, 2005-03-29 at 05:50 -0800, Stephan Szabo wrote:
> On Tue, 29 Mar 2005, Simon Riggs wrote:
>
> > On Tue, 2005-03-29 at 01:48 -0700, Karim A Nassar wrote:
> > > > Each value has 1/13th of the table, which is too many rows per value to
> > > > make an IndexScan an efficient way of deleting ro
Simon Riggs <[EMAIL PROTECTED]> writes:
> If action is NO ACTION or RESTRICT then
> we need to SELECT at most 1 row that matches the criteria
> which means we can use LIMIT 1
> If action is CASCADE, SET NULL, SET DEFAULT then
> we need to UPDATE or DELETE all rows that match the
On Tue, 2005-03-29 at 09:56 -0500, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > If there were some way to pass a "limit" into SPI_prepare that was treated
> > similarly to a LIMIT clause for planning purposes but didn't actually
> > change the output plan to only return that numb
On Tue, 2005-03-29 at 10:31 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > If action is NO ACTION or RESTRICT then
> > we need to SELECT at most 1 row that matches the criteria
> > which means we can use LIMIT 1
>
> > If action is CASCADE, SET NULL, SET DEFAULT then
On Tue, 29 Mar 2005, Simon Riggs wrote:
> On Tue, 2005-03-29 at 10:31 -0500, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > If action is NO ACTION or RESTRICT then
> > > we need to SELECT at most 1 row that matches the criteria
> > > which means we can use LIMIT 1
> >
> > >
On Tue, 29 Mar 2005, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > If there were some way to pass a "limit" into SPI_prepare that was treated
> > similarly to a LIMIT clause for planning purposes but didn't actually
> > change the output plan to only return that number of rows, w
On Tue, 2005-03-29 at 09:40 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > ...but, I see no way for OidFunctionCall8 to ever return an answer of
> > "always just 1 row, no matter how big the relation"...so tuples_fetched
> > is always proportional to the size of the relation.
Simon Riggs <[EMAIL PROTECTED]> writes:
> That implies to me that LIMIT queries are not considered correctly in
> the M&L formula and thus we are more likely to calculate a too-high cost
> for using an index in those circumstancesand thus more likely to
> SeqScan for medium sized relations?
Yo
Dave Cramer <[EMAIL PROTECTED]> writes:
> PFC wrote:
> >
> > My Laptop does 19 MB/s (reading <10 KB files, reiser4) !
>
> Yeah, 35Mb per sec is slow for a raid controller, the 3ware mirrored is
> about 50Mb/sec, and striped is about 100
Well you're comparing apples and oranges here. A modern
Hi everybody...
I'm new hear, and I will try to explain my problem, and maybe I can
get a help...
I'm writing a software for 3 years, and this software has the position
GPS from vehicles, and other informations.
My problem starts when I had to store all the data about the vehicles,
about 1 or 2
On Tue, 2005-03-29 at 12:31 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > That implies to me that LIMIT queries are not considered correctly in
> > the M&L formula and thus we are more likely to calculate a too-high cost
> > for using an index in those circumstancesand th
On Tue, Mar 29, 2005 at 03:33:24PM -0300, Vinicius Bernardi wrote:
>
> But now the problem starts when I has to select data from this
> vehicles about the history ( I store only 2 months ) something like 40
> or 50 millions of data about 500 vehicles.
>
> Using the keys VEHICLE_ID and GPS_TIME, th
At now I have this system runing in a mysql, all the examples I have
are in mysql, but the biggest client that will start now, we will use
PostgreSQL, so I need a way to do those questions in postgres...
Ideas like TABLESPACES or anothe things...
Just looking for start ideas...
Thanks
Vinicius M
I recently pg_dumpall'd my DB from a (used for testing) v20z install of
postgresql 8.0.1, and restored it to my production (but not yet in
service) v40z running the same version. The test DB has had multiple
millions of rows created/dropped during testing. The results of VACUUM
VERBOSE are giving m
23 matches
Mail list logo
