2nd Call for Papers
Roy Hann
conference in June. You just have to do a 40 minute presentation on any
of the Actian products: Vectorwise, OpenROAD or Ingres. (Or some of the
newer ones.)
Submit a very brief outline or abstract of what you would like to talk
about at paper...@uk-iua.org by May 10.
(If you don't submit a paper you can still get a discounted registration
until tomorrow. Register using the link below.)
--
Roy
UK Actian User Association Conference 2013 will be on Tuesday June 11 2013.
Register today at http://www.regonline.co.uk/ukiua2013
*** EARLY BIRD REGISTRATION DISCOUNT TILL MAY 3rd ***
Roy Hann
> Submit a very brief outline or abstract of what you would like to talk
> about at paper...@uk-iua.org by May 10.
paper...@uk-iua.org.uk.
Patrick COURANT
May be you will again give me hope.
Well. I have this client I am trying to give advice to.
It shows me Sql Server 2005, with very poor performance. This happens.
But the situation is interesting.
In their business, they build one table each and every time (meaning every several seconds), adding to the database (Yes!!) when one of their client send I don't know exactly what, and I don't know exactly with what columns (but not many, that I know) or what information.
The consequence being that, at 4 p.m in the afternoon, they have to handle something like 400 000 (4 hundred thousand) tables. AT LEAST.
The purpose of those tables is reporting (so they say).
My answer was to quote the possibility of management of those tables with some kind of pointer, included in some kind of table, but, most important, indexed in hash, taking into account these informations are always accessed in one unity.
Problem: hash is almost unknown with SqlServer. Only Btree is casher, which looms to be disastrous.
How high are the risks on my life to advise with ingres 10 (I don't quote vectorwise, they don't want this kind of database), to solve the problem, with a quite ridiculously simple index hash, as powerful as ingres provides?
And will I stay as alone as usual when I do advise Ingres with my prospects, under the rigid glaring look of my Actian friends??
Thank you for any commitment to my misery.
Regards to all.
Patrick
Patrick COURANT, alas faithful to ingres.
> Info-Ingres mailing list
> Info-...@kettleriverconsulting.com
> http://ext-cando.kettleriverconsulting.com/mailman/listinfo/info-ingres
Roy Hann
> May be you will again give me hope.
sounds like a rule-based partitioning problem, probably using a hash
rule.
Ingres 10S, 10, 9.2, whatever. They'll all do it.
Roy
--
UK Actian User Association Conference 2014 will be on Tuesday June 11 2014.
Mark the date in your diary.
Laframboise, André
Hi,
Looks like self-induced misery to me.
I’d question the application, not the DB. Looks like a very bad design. Are all these tables a 1 row tables ?
If possible, I’d change the create table to an insert into a global table. If that’s not possible, then an hourly process that’s copies the data from these small tables into a single table, then drop the small tables. This is for reporting purposes ?
And of course, I’d use Ingres above SQL Server anyday J
Andre
From: info-ingr...@kettleriverconsulting.com [mailto:info-ingr...@kettleriverconsulting.com]
On Behalf Of Patrick COURANT
Sent: June-20-13 1:47 PM
To: Roy Hann
Subject: [Info-Ingres] Witness of some misery
Hello my friends Roy, Karl, Paul, Martin and all the awsome gurus ...
May be you will again give me hope.
Well. I have this client I am trying to give advice to.
It shows me Sql Server 2005, with very poor performance. This happens.
But the situation is interesting.
In their business, they build one table each and every time (meaning every several seconds), adding to the database (Yes!!) when one of their client send I don't know exactly what, and I don't know exactly with what columns (but not many, that I know) or what
information.
The consequence being that, at 4 p.m in the afternoon, they have to handle something like 400 000 (4 hundred thousand) tables. AT LEAST.
The purpose of those tables is reporting (so they say).
My answer was to quote the possibility of management of those tables with some kind of pointer, included in some kind of table, but, most important, indexed in hash, taking into account these informations are always accessed in one unity.
Problem: hash is almost unknown with SqlServer. Only Btree is casher, which looms to be disastrous.
How high are the risks on my life to advise with ingres 10 (I don't quote vectorwise, they don't want this kind of database), to solve the problem, with a quite ridiculously simple index hash, as powerful as ingres provides?
And will I stay as alone as usual when I do advise Ingres with my prospects, under the rigid glaring look of my Actian friends??
Thank you for any commitment to my misery.
Regards to all.
Patrick
Patrick COURANT, alas faithful to ingres.
> From:
spec...@processed.almost.meat
> Date: Thu, 2 May 2013 19:08:50 +0000
> To: info-...@kettleriverconsulting.com
> Subject: Re: [Info-Ingres] 2nd Call for Papers (CORRECTION)
>
Patrick COURANT
Thanks a lot for your answer.
You might think rightfully that I tried very awkwardly to make some kind of humour.
Still, and seriously, I am very happy to receive your advice. I am NOT WRONG to keep believing in Ingres.
In France where I live, it is not that obvious these days.
For that, and your view of a possible solution, again thanks a lot.
Patrick.
From: Andre.La...@bac-lac.gc.ca
To: info-...@kettleriverconsulting.com
Date: Thu, 20 Jun 2013 18:37:45 +0000
Subject: Re: [Info-Ingres] Witness of some misery
> _______________________________________________
> Info-Ingres mailing list
> Info-...@kettleriverconsulting.com
>
http://ext-cando.kettleriverconsulting.com/mailman/listinfo/info-ingres
Kim Ginnerup
> _______________________________________________
> Info-Ingres mailing list
> Info-...@kettleriverconsulting.com
> http://ext-cando.kettleriverconsulting.com/mailman/listinfo/info-ingres
_______________________________________________ Info-Ingres mailing list Info-...@kettleriverconsulting.com http://ext-cando.kettleriverconsulting.com/mailman/listinfo/info-ingres