My best regards for all...
Please. I need for an advice.
I'm having a trouble, that puting others queries in wait state, becouse
of ExclusiveLock granted by an Update that only update one row at each
time. This update occurs into a function and this function are
executed several times and c
My best regards for all...
Please. I need for an advice.
I'm having a trouble, that puting others queries in wait state, becouse
of ExclusiveLock granted by an Update that only update one row at each
time. This update occurs into a function and this function are
executed several times and c
> Greg's book is awesome. It really gives a lot of informations/tips/whatever
> on performances. I mostly remember all the informations about hardware, OS,
> PostgreSQL configuration, and such. Not much on the EXPLAIN part.
Arrived this morning :)
> http://www.pgcon.org/20
Hi Jeff
> It kind of does. The expected speed is predicated on the number of rows
being 200 fold higher. If the number of rows actually was that much higher,
the two speeds might be closer together. That is why it would be
interesting to see a more typical case where the actual number of rows i
> I also wonder if increasing (say x10) of default_statistics_target or just
doing ALTER TABLE SET STATISTICS for particular tables will help.
> It will make planned to produce more precise estimations. Do not forget
ANALYZE afer changing it.
Thanks Sergey, I will try this too.
I think the bother
That is very interesting indeed, these indexes are quite large!
I will apply that patch and try it out this evening and let you know.
Thank you very much everyone for your time, the support has been amazing.
PS: Just looked at this thread on the archives page and realised I don't
have my name in
Ah okay, thanks. I knew I could set various things but not
effective_work_mem (I tried reloading the edited config file but it didn't
seem to pick it up)
From: Vitalii Tymchyshyn [mailto:tiv...@gmail.com]
Sent: 04 December 2012 18:51
To: postgre...@foo.me.uk
Cc: postgres performance list
Su
Ah, okay - my reasoning was there's a big fancy-pants raid array behind it
that makes disk operations faster relative to CPU ones.
I'll test it and see if it actually makes any difference.
-Original Message-
From: Claudio Freire [mailto:klaussfre...@gmail.com]
Sent: 04 December 2012 18:3
> But the row estimates are not precise at the top of the join/filter.
> It thinks there will 2120 rows, but there are only 11.
> So it seems like there is a negative correlation between the two tables
which is not recognized.
Yes, you are right there. I am only just beginning to understand how t
>> But the row estimates are not precise at the top of the join/filter.
>> It thinks there will 2120 rows, but there are only 11.
>Ah... I didn't spot that one...
Yes, you are right there - this is probably a slightly atypical query of
this sort actually, 2012 is a pretty good guess.
On Claudio
2Ghz cores.
The postgres configuration is here:
http://pastebin.com/48uyiak7
I am using a 64bit postgresql 9.2.1, hand compiled on a RedHat 6.2 box.
QUERY:
--
What I want to do is sum all of the position effects, for a particular asset
while joined to the trade table to filter for the time it wa
I am using a 64bit postgresql 9.2.1, hand compiled on a RedHat 6.2 box.
QUERY:
--
What I want to do is sum all of the position effects, for a particular asset
while joined to the trade table to filter for the time it was executed and
the book it was traded into:
SELECT sum(position_effect.qua
Start up your PostgreSQL instance with the MD as the data store
4. Load your data to the MD instance.
5. Figure out how you will change indexes _and_ ensure that your disk
storage is consistent with your MD instance.
I haven't done so, but it would be interesting to have a secondary
database
Rodrigo Madera wrote:
I am concerned with performance issues involving the storage of DV on
a database.
I though of some options, which would be the most advised for speed?
1) Pack N frames inside a "container" and store the container to the db.
2) Store each frame in a separate record in the
We're storing tif images in a table as bytea. We were running low on our
primary space and moved several tables, including the one with the images,
to a second tablespace using ALTER TABLE SET TABLESPACE.
This moved quite cleaned out quite a bit of space on the original
tablespace, but not as m
.
Kudos to you Greg, thanks Luke for your comment (though it seems to disagree
with my experience). Also to Dennis, there were not drastic changes in the
plan between 8.0 and 8.1, it was just the actual execution times.
Martin
"PostgreSQL" <[EMAIL PROTECTED]> wrote in mess
SELECT v_barcode, count(v_barcode) FROM lead GROUP BY v_barcode HAVING
count(*) > 1;
This is a pretty good example of the place where 8.1 seems to be quite
broken. I understand that this query will want to do a full table scan
(even through v_barcode is indexed). And the table is largish, at
I'm seeing some other little oddities in the beta as well. I'm watching an
ALTER TABLE ADD COLUMN right now that has been running almost two hours. I
stopped it the first time at 1 hour; I suppose I'll let it go this time and
see if it ever completes. The table is about 150K rows. Top, vmsta
We're running 8.1beta3 on one server and are having ridiculous performance
issues. This is a 2 cpu Opteron box and both processors are staying at 98
or 99% utilization processing not-that-complex queries. Prior to the
upgrade, our I/O wait time was about 60% and cpu utilization rarely got very
Postgres is somewhat speed-challenged on aggregate functions.
The most-repeated work-around would be something like:
SELECT u.user_id,
(SELECT activity_date
FROM user_activity
WHERE user_activity.user_id = pp_users.user_id
AND user_activity_type_id = 7
ORDER BY activity_date DESC
LIMIT 1
Thank each of you for your replies. I'm just beginning to understand the
scope of my opportunities.
Someone (I apologize, I forgot who) recently posted this query:
SELECT oid::regclass, reltuples, relpages
FROM pg_class
ORDER BY 3 DESC
Though the application is a relatively low-volu
Is there a rule-of-thumb for determining the amount of system memory a
database requres (other than "all you can afford")?
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Hello all!
Do anyone have experience installing Postgres 7.3.4 on Slackware 9.1?
Do exist any trouble, bug, problem... or is a good MIX?
I want to "leave" RedHat (9) because is not "free" anymore and i don't
want to use fedora BETA TEST versions.
Any suggestion?
THANKS ALL.
--
23 matches
Mail list logo
