Christopher Weimann <[EMAIL PROTECTED]> writes:
> You can do snapshots in FreeBSD 5.x with UFS2 as well but that (
> nor XFS snapshots ) will let you backup with the database server
> running. Just because you will get the file exactly as it was at
> a particular instant does not mean that the pos
Kari,
> users: "users_upper_nick" unique, btree (upper((nick)::text))
> image: "image_uid_status" btree (uid, status)
Odd ... when did you last run ANALYZE on "users"?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)-
"Loeke" <[EMAIL PROTECTED]> writes:
> do views exist fysically a separate "table", or are they generated
> on the fly whenever they are queried?
Views are implementing by rewriting queries into the appropriate query
on the view's base tables.
http://www.postgresql.org/docs/current/static/rules-vi
"[EMAIL PROTECTED] (Nick Barr)" stated in
comp.databases.postgresql.performance:
> [EMAIL PROTECTED] wrote:
[sNip]
>> Sorry I m a little bit confused about the persistent thing!!
>> Is it smart to use persistent connections at all if i expect 100K
>> Users to hit the script in an hour and the sc
Arnau wrote:
explain analyze select * from statistics2 where timestamp_in <
to_timestamp( '20031201', 'MMDD' );
NOTICE: QUERY PLAN:
Seq Scan on statistics2 (cost=0.00..638.00 rows=9289 width=35) (actual
time=0.41..688.34 rows=27867 loops=1)
Total runtime: 730.82 msec
That query is not using
do views exist fysically a separate "table",
or are they generated on the fly whenever they are queried?
if they exist fysically they could improve performance (..php, web),
for example a view being a join between two or more tables..
tnx?
---(end of broadcast)-
On 01/23/2004-10:18AM, Joshua D. Drake wrote:
>
> XFS also has the interesting ability (although I have yet to test it)
> that will allow you
> to take a snapshot of the filesystem. Thus you can have filesystem level
> backups
> of the PGDATA directory that are consistent even though the databas
Hi all,
First of all thanks to Josh and Richard for their replies. What I have
done to test
their indications is the following. I have created a new table identical to
STATISTICS,
and an index over the TIMESTAMP_IN field.
CREATE TABLE STATISTICS2
(
STATISTIC_IDNUMERIC(10) NOT NULL DEFAULT
David Teran <[EMAIL PROTECTED]> writes:
>> I recall that we saw similar symptoms once before, and I thought we'd
>> fixed it, but I didn't find any relevant mentions in the CVS logs.
>>
>> What version are you running, exactly?
> 7.4.1, build from sourcecode. Running on MacOS X Server 10.3.2, dua
HI Tom.
I got a little distracted by the bizarre actual-time values shown for
some of the query steps:
-> Merge Join (cost=2451266.53..2655338.83 rows=13604393
width=8)
(actual time=82899.466..-2371037.726 rows=2091599 loops=1)
-> Sort (cost=2451169.10..2483246.47 rows=12830947
On Friday 30 January 2004 19:19, Tom Lane wrote:
>
> The hash-join total time is obviously wrong seeing that the total
> runtime is only about 10 msec, and the negative values for the other
> two are even more obviously wrong.
>
> I recall that we saw similar symptoms once before, and I thought
Stephan, Tom-
Thanks. I now see that DISTINCT can't be moved within the plan as I thought. This is exactly the thinko that I was hoping someone would expose.
I've decided to abandon the DISTINCT clause. The view is more general and sufficiently fast without it, and callers can always add it t
David Teran <[EMAIL PROTECTED]> writes:
> [ query plan ]
I got a little distracted by the bizarre actual-time values shown for
some of the query steps:
> -> Merge Join (cost=2451266.53..2655338.83 rows=13604393 width=8)
> (actual time=82899.466..-2371037.726 rows=2091599 loops=1)
>
Hi,
On 30.01.2004, at 19:10, Stephan Szabo wrote:
On Fri, 30 Jan 2004, David Teran wrote:
select
sum(job_property_difference(t0.int_value, t1.int_value)) as rank
from
job_property t0,
job_property t1
where
t0.id_job_profile = 911
and t0.id_job_attribute = t1.id_job_attribute
On Fri, 30 Jan 2004, David Teran wrote:
> select
> sum(job_property_difference(t0.int_value, t1.int_value)) as rank
>from
>job_property t0,
>job_property t1
>where
>t0.id_job_profile = 911
>and t0.id_job_attribute = t1.id_job_attribute
>and t1.id_job_profile in (select
On Jan 30, 2004, at 11:00 AM, David Teran wrote:
executing a select like this:
select
sum(job_property_difference(t0.int_value, t1.int_value)) as rank
from
job_property t0,
job_property t1
where
t0.id_job_profile = 911
and t0.id_job_attribute = t1.id_job_attribute
and t1.id_job_profi
Hi,
its me again. As far as we tested postgresql ist fast, very fast
compared to the other db system we test and are using currently.
We are now testing some test databases on Postgres. We use one
function which simply calculates a difference between two values and
checks if on value is 0,
On Thu, 2004-01-29 at 23:23, Dennis Bjorklund wrote:
> On Thu, 29 Jan 2004, Jack Coates wrote:
>
> > > Probably better to repost it as a gzip'd attachment. That should
> >
> > complete with a picture of the GUI version. 26k zipped, let's see if
> > this makes it through.
>
> Are you sure you at
Kari Lavikka <[EMAIL PROTECTED]> writes:
> Postgres seems to estimate the cost of indexscan to be a bit too high.
> The table has something like 50 rows and I have run reindex and vacuum
> analyze recently. Is there something to tune?
I think the real problem here is that the row estimate is o
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> Getting rid of the group by would not give that kind of speedup?
No. Getting rid of the per-row subqueries (or at least finding a way to
make 'em a lot cheaper) is the only way to make any meaningful change.
regards, tom lane
Bill Moran wrote:
Basically, all I do is call each query in turn until I've collected all the
results, then marshall the results in to a SOAP XML response (using gsoap,
if anyone's curious) and give them back to the client application. It's
the client app's job to figure out what to do with them,
Tom Lane <[EMAIL PROTECTED]> writes:
> Jack Coates <[EMAIL PROTECTED]> writes:
> > yup -- here it is. It will probably be a nasty mess after linewrap gets
> > done with it,
>
> yup, sure is :-( If I was familiar with the layout I could probably
> decipher where the line breaks are supposed to b
Hi, more strange plans ...
Planner estimates an indexscan to return 240 rows although it is using a
unique index and chooses to use hash join and seqscan instead of nested
loop and indexscan. It's ... very slow.
Idexes used:
users: "users_upper_nick" unique, btree (upper((nick)::text))
imag
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> My guess is that the original SQL was
> WHERE ... date_from = current_timestamp
> This should be
> WHERE ... date_from = localtimestamp
> if timestamp without tz is the intended column datatype.
Thank you. The problem was exactly this:
Hi,
Postgres seems to estimate the cost of indexscan to be a bit too high.
The table has something like 50 rows and I have run reindex and vacuum
analyze recently. Is there something to tune?
Index is a multicolumn index:
"admin_event_stamp_event_type_name_status" btree (stamp, event_typ
On Thu, 29 Jan 2004, Jack Coates wrote:
> > Probably better to repost it as a gzip'd attachment. That should
>
> complete with a picture of the GUI version. 26k zipped, let's see if
> this makes it through.
Are you sure you attached it?
At least when it got here there was no attachment.
--
/
On Thu, 29 Jan 2004, Tom Lane wrote:
> > jackdb-# GROUP BY memberid_ HAVING (
>
> Um, that's not what I had in mind at all. Does GROUP BY actually do
> anything at all here? (You didn't answer me as to whether memberid_
> is a unique identifier or not, but if it is, this GROUP BY is just an
>
27 matches
Mail list logo
