On Wednesday 19 September 2001 11:25, Tom Lane wrote:
> Denis Perchine <[EMAIL PROTECTED]> writes:
> > BTW, using begin; lock table; create index;drop index;commit; is not
> > working,
>
> ??
>
> regression=# create table foo (f1 text);
> CREATE
> re
On Wednesday 19 September 2001 11:25, Tom Lane wrote:
> Denis Perchine <[EMAIL PROTECTED]> writes:
> > BTW, using begin; lock table; create index;drop index;commit; is not
> > working,
>
> ??
>
> regression=# create table foo (f1 text);
> CREATE
> re
updates it is not an issue too (I mean if do not update more than
25% of DB each day).
Actually for anyone listening for such advices I would recommend to create a
test installation, and stress test it before go to production. Interbase has
its own problems.
--
Sincerely Yours,
Denis Perchi
There are some still. Although not that large as mentioned in the comments.
If you have long-running cursor, and tables involved in this cursor are
heavily updated, you will end with 200Mb postmaster in 1-2 days.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROT
.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
jump from 8 in load to 32 without any real reason
> nor too
> much requests.
>
> I already do vacuum even on the fly ifever that can decrease
> load, but
> nothing...
>
> I've done many indexed also...
>
> Can someone hel
records take a so long time ? :-/
Which queries? Could you please provide explain of them? Could you please
provide execution stats for them under load?
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
EXPLAIN
Cost is something really wierd Why?
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
n select * from users where variant_id=5 AND active='f'
order by rcptdate,variant_id,active limit 60;
NOTICE: QUERY PLAN:
Limit (cost=13005.10..13005.10 rows=60 width=145)
-> Sort (cost=13005.10..13005.10 rows=3445 width=145)
-> Index Scan using users_rcptdate_vid_key on users
(cost=0.00..12658.35 rows=3445 width=145)
EXPLAIN
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
type,
> and pg_index, plus the indexes on those tables, but that doesn't seem
> like it'd amount to anything close to 8K per LO.
>
> 7.1 avoids this problem by keeping all LOs in one big table.
Or you can use my patch for the same functionality in 7.0.x.
You can get
link is: http://www.perchine.com/dyp/pg/
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
On 14 November 2000 07:33, Hiroshi Inoue wrote:
> Denis Perchine wrote:
> > Hello,
> >
> > I have very interesting problem. I have quite highly loaded database.
> > Once a day I create new indices, and after that drop old ones. Ido this
> > one by one.
>
> Y
Hello,
any ideas what this message mean?
ERROR: Index 1821202 does not exist
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
> On Thu, Nov 02, 2000 at 05:35:04PM +0600, Denis Perchine wrote:
> > Except on case... When you would like to be sure in transaction safety...
>
> Ok, but not for image galery.
Again... If you can accept that you will have half of image, it's OK.
If not...
--
Sincerely Y
>
> Really, you can show images from database, BUT
> there are no much reasons put in database something, for which you can't
> say WHERE field=some_thing
> Better place images into filesystem.
Except on case... When you would like to be sure in tr
y. But I don't think PHP and others have this
> possibility. But Cold Fusion costs 1300$ :(
No, PHP has this.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
ix_limits_sid_type: Pages 81; Tuples 9404: Deleted 279. CPU
0.01s/0.02u sec.
psql:/home/www/www.webmailstation.com/sql/vacuum.limits.sql:1: ERROR:
Parent tuple was not found
---
--
Sincerely Yours,
Denis Perchine
--
E
rforms. I'm leery
> > of database-specific APIs.
>
> As far as I have listen, it looks like a nice way to optimize searches
> in
> blobs. Don't know anything else.
>
> Saludos... :-)
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
> Denis Perchine <[EMAIL PROTECTED]> writes:
> > As far as you can see it uses sequence scan for inner select. This is
> > quite strange as if I do this select with a constant it will use index
> > scan:
>
> Are the two tables' "email" fie
on the first column and calculate all others this will be much
faster than sequence scan.
Any thoughts?
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
Hello,
is it possible to create functional indices with constant params?
I tried to do
create index ix_s_m on stats(date_part('month', sent_date));
And get
ERROR: parser: parse error at or near "'"
If it is not possible is there any workarounds for this?
--
Sincer
Hello,
Just a small question: why there is not any quoting routine in libpq.
This is very handy to have one. And also it is quite hard always
write quoting routing for database if you want to have cross database code.
--
Sincerely Yours,
Denis Perchine
--
E
hile processing the request.
> regression=#
>
> which looks pretty reasonable.
>
> I should also point out that in the current system, normal shutdown
> (via pg_ctl stop or 'kill' on the postmaster) produces no such result
> because extant backends are allow
nd I should try to reconnect.
Any ideas how this can be implemented?
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
> i have start postgresql doingpostmaster -i &
>
> and this is what i am getting in the shell.
>
> NOTICE: DateStyle is Postgres with US (NonEuropean) conventions
> NOTICE: DateStyle is Postgres with US (NonEuropean) conventions
> NOTICE: DateStyle is Postgres with US (NonEuropean) conve
-> Index Scan using dicts_id_key on dicts (cost=0.00..2.02
rows=1 width=16)
-> Index Scan using dicts_id_key on dicts (cost=0.00..2.02 rows=1
width=16)
-> Index Scan using dicts_id_key on dicts (cost=0.00..2.02 rows=1 width=16)
-> Index Scan using dicts_id_key on dicts (cost=0.00..2.02 rows=1 width=16)
EXPLAIN
Again... Lot's of index scans on the same table... Is it possible to do one scan and
avoid lot's of index scans? Sorry to bother, but I created views to avoid multiple
scans...
But...
DISCLAMER: after any change vacuum analyze was made. :-))) Just to avoid some
questions.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
26 matches
Mail list logo
