On Thu, Apr 20, 2006 at 11:07:31 +0530,
soni de <[EMAIL PROTECTED]> wrote:
> Please provide me some help regarding how could I use cursor in following
> cases? :
>
> I want to fetch 50 records at a time starting from largest stime.
>
> SELECT * FROM wan ORDER BY stime LIMIT 50 OFFSET 81900;
So
Please provide me some help regarding how could I use cursor in following cases? :
I want to fetch 50 records at a time starting from largest stime.
Total no. of records in the "wan" table:
82019
pdb=# \d wan
Table "wan"
Column | Type
Christopher Kings-Lynne wrote:
Scott Marlowe <[EMAIL PROTECTED]> writes:
It's the refusal of people to stop using MyISAM table types that's the
real issue.
Isn't MyISAM still the default over there? It's hardly likely that the
average MySQL user would use anything but the default table type .
Scott Marlowe <[EMAIL PROTECTED]> writes:
It's the refusal of people to stop using MyISAM table types that's the
real issue.
Isn't MyISAM still the default over there? It's hardly likely that the
average MySQL user would use anything but the default table type ...
Since MySQL 5, InnoDB table
Tom,
You are absolutely correct about not having run ANALYZE
on the particular table.
In my attempt to create a simple "test case" I created that
table (pk_c2) from the original and had not run ANALYZE
on it, even though, ANALYZE had been run prior to building
that table.
The problem on the test
On Wed, 2006-04-19 at 10:31, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > It's the refusal of people to stop using MyISAM table types that's the
> > real issue.
>
> Isn't MyISAM still the default over there? It's hardly likely that the
> average MySQL user would use anything bu
Isn't MyISAM still the default over there?
Yes, it's the default.
Personnally I compile MySQL without InnoDB... and for any new development
I use postgres.
It's hardly likely that the average MySQL user would use anything but
the default table type ...
Double yes ; also many
Scott Marlowe <[EMAIL PROTECTED]> writes:
> It's the refusal of people to stop using MyISAM table types that's the
> real issue.
Isn't MyISAM still the default over there? It's hardly likely that the
average MySQL user would use anything but the default table type ...
reg
On Wed, 2006-04-19 at 07:08, Markus Schaber wrote:
> Hi, Magnus,
>
> Magnus Hagander wrote:
>
> > Bacula already serializes access to the database (they have to support
> > mysql/myisam), so this shouldn't help.
>
> Ouch, that hurts.
>
> To support mysql, they break performance for _every other
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> Actually, [commit_delay] might well hurt by introducing extra delays.
>>
>> Well, if you read the documentation, you will see that it
>> will only wait if there are at least commit_siblings other
>> transactions active. So when Bacula serializes
Hi, Magnus,
Magnus Hagander wrote:
>>To support mysql, they break performance for _every other_
>>database system?
> Actually, it probably helps on SQLite as well.
AFAICS from the FAQ http://www.sqlite.org/faq.html#q7 and #q8, SQLite
does serialize itsself.
> And considering they only
> suppor
> > Bacula already serializes access to the database (they have
> to support
> > mysql/myisam), so this shouldn't help.
>
> Ouch, that hurts.
>
> To support mysql, they break performance for _every other_
> database system?
Actually, it probably helps on SQLite as well. And considering they o
Hi, Magnus,
Magnus Hagander wrote:
> Bacula already serializes access to the database (they have to support
> mysql/myisam), so this shouldn't help.
Ouch, that hurts.
To support mysql, they break performance for _every other_ database system?
Now, I understand how the mysql people manage to s
On Wed, 2006-04-19 at 08:00, Theo Kramer wrote:
> I tried this on my test system running 8.1.3 and appears to work fine.
> Appreciate it if you could let me know in what cases it does not work
> properly.
Please ignore - 'Explain is your friend' - got to look at the tips :)
--
Regards
Theo
---
On Tue, 2006-04-18 at 19:00 +0200, PFC wrote:
> Suppose you have a table codes :
> (
> game_id INT,
> codeTEXT,
> usedBOOL NOT NULL DEFAULT 'f',
> prize ...
> ...
> PRIMARY KEY (game_id, code)
> )
>
> Just UPDATE codes SET
On Tue, 2006-04-18 at 11:33 -0400, Tom Lane wrote:
> Mario Splivalo <[EMAIL PROTECTED]> writes:
> >> If there is concurrent locking,
> >> you're also running a big risk of deadlock because two processes might
> >> try to lock the same rows in different orders.
>
> > I think there is no risk of a d
16 matches
Mail list logo
