Hi,
I'am taking dump of a huge database and do not want the restoration of
that dump to take a lot of time as is the case when you take the dump in
text files. I want to take the dump as an archive file and get it restored
in very less time. I'am not able to figure out what is the command for
t
Hi!
I have 4 question which probably someone can answer.
1) I have a transaction during which no data was modified, does it
make a difference whether i send COMMIT or ROLLBACK? The effect is the
same, but what´s about the speed?
2) Is there any general rule when the GEQO will start using an ind
On Monday 01 December 2003 18:37, Evil Azrael wrote:
> 1) I have a transaction during which no data was modified, does it
> make a difference whether i send COMMIT or ROLLBACK? The effect is the
> same, but what´s about the speed?
It should not matter. Both commit and rollback should take same amo
Greetings:
Apologies if this question has already been answered, but I was unable to locate a prior answer in the archives...
I have a table with approximately 10 million records, called "indethom", and with an INTEGER column called "clavis" which is set up as a primary key. When I try to perfor
On Mon, Dec 01, 2003 at 02:07:50PM +0100, Evil Azrael wrote:
> 1) I have a transaction during which no data was modified, does it
> make a difference whether i send COMMIT or ROLLBACK? The effect is the
> same, but what´s about the speed?
It makes no difference.
> 2) Is there any general rule whe
On Mon, Dec 01, 2003 at 02:40:30PM +0100, Erik Norvelle wrote:
>
> it=> explain select * from indethom where clavis < 25;
What's the percentage of the table where clavis < 25? Have you
ANALYSEd recently? What does the pg_stats view tell you about this
table?
> Feel free to point me to any F
On Mon, 1 Dec 2003 15:47:47 +0530
"Kamalraj Singh Madhan" <[EMAIL PROTECTED]> wrote:
> Hi,
> I'am taking dump of a huge database and do not want the
> restoration of
> that dump to take a lot of time as is the case when you take the dump
> in text files. I want to take the dump as an archi
On Wed, 2003-11-26 at 16:32, Hannu Krosing wrote:
> Jeremiah Jahn kirjutas K, 26.11.2003 kell 22:14:
> > I was wondering if there is something I can do that would act similar to
> > a index over more than one table.
> >
> > I have about 3 million people in my DB at the moment, they all have
> > r
On Mon, 1 Dec 2003, Jeff wrote:
> On Mon, 1 Dec 2003 15:47:47 +0530
> "Kamalraj Singh Madhan" <[EMAIL PROTECTED]> wrote:
>
> 4. If you are not using 7.4 and using pg_dump, there isn't much you can
> do about adding foreign keys going stupidly slow :(
You can take a schema dump and a separate dat
The ANALYSE did the trick... Thanks! Will also read through the
archives...
-Erik
On lunes, dici 1, 2003, at 15:04 Europe/Madrid, Andrew Sullivan wrote:
On Mon, Dec 01, 2003 at 02:40:30PM +0100, Erik Norvelle wrote:
it=> explain select * from indethom where clavis < 25;
What's the percentage o
On Monday 01 December 2003 14:29, Jeremiah Jahn wrote:
> On Wed, 2003-11-26 at 16:32, Hannu Krosing wrote:
> > Jeremiah Jahn kirjutas K, 26.11.2003 kell 22:14:
> > > I was wondering if there is something I can do that would act similar
> > > to a index over more than one table.
> > >
> > > I have a
> Jeremiah Jahn wrote:
>
> > Have you run ANALYZE ? Why does DB think that there is only
> one judge
> > with name like SMITH% ?
> I've attached the Analyze below. I have no idea why the db
> thinks there is only 1 judge named simth. Is there some what
> I can inform the DB about this. In actua
Turning enable_hashjoin off made the query run as it had on v7.3. We
have worked around this by changing the index from a function call to a
direct index on a new column with the results of the function maintained
by a trigger. Would there be performance issues from leaving
enable_hashjoin o
Roger Ging <[EMAIL PROTECTED]> writes:
> See results below.
Thanks for the report. It seems the issue is that the estimate for the
number of matching rows is way off (870 vs 8):
>-> Index Scan using idx_program_mri_id_no_program on program p
> (cost=0.00..3400.74 rows=870 width=40) (actua
Jeremiah,
> I've attached the Analyze below. I have no idea why the db thinks there
> is only 1 judge named simth. Is there some what I can inform the DB
> about this. In actuality, there aren't any judges named smith at the
> moment, but there are 22K people named smith.
No, Hannu meant that you
Tom,
Turning enable_hashjoin off made the query run as it had on v7.3. We
have worked around this by changing the index from a function call to a
direct index on a new column with the results of the function
maintained by a trigger. Would there be performance issues from
leaving enable_hashj
Hi!
I have 4 question which probably someone can answer.
1) I have a transaction during which no data was modified, does it
make a difference whether i send COMMIT or ROLLBACK? The effect is the
same, but what´s about the speed?
2) Is there any general rule when the GEQO will start using an ind
I am currently working on optimizing some fairly time consuming queries
on a decently large
dataset.
The Following is the query in question.
SELECT z.lat, z.lon, z.city, z.state, q.date_time, c.make, c.model, c.year
FROM quotes AS q, zips AS z, cars AS c
WHERE
z.zip = q.zip
Hello,
I am wondering if it is possible to use several
machine as cluster to boost the slow queries. Is
that possible? Anybody have tried that before?
Initially, I was thinking to use dual CPUS instead
of one. but it is not correct because pgsql is not
multi-threaded.
Any suggestions are welcome
LIANHE SHAO wrote:
> Hello,
> I am wondering if it is possible to use several
> machine as cluster to boost the slow queries. Is
> that possible? Anybody have tried that before?
>
> Initially, I was thinking to use dual CPUS instead
> of one. but it is not correct because pgsql is not
> multi-thr
Jared Carr <[EMAIL PROTECTED]> writes:
> I am currently working on optimizing some fairly time consuming queries
> on a decently large dataset.
It doesn't look that large from here ;-). I'd suggest experimenting
with reducing random_page_cost, since at least for your test query
it sure looks lik
21 matches
Mail list logo
