On Wed, 25 Aug 2004, Richard Huxton wrote:
> > Index Scan using trptserc on trans (cost=0.00..465.10 rows=44 width=118)
> >Index Cond: (trn_patno = 19)
> >Filter: ((trn_old_date >= '1994-08-23'::date) AND (trn_old_date <=
> > '2004-08-23'::date) AND (trn_bill_inc = 'B'::bpchar))
> >
Josh Berkus wrote:
Mark, Tim,
select
pav1.person_id
from
person_attributes_vertical pav1
where
(pav1.attribute_id = 1
and pav1.value_id in (2,3))
or (pav1.attribute_id = 2
and pav1.value_id in (2,3))
Not the same query, sorry. Daniel's query yields all the person_
I see that PG has a one-shot CLUSTER command, but doesn't support
continuously-updated clustered indexes.
What I infer from newsgroup browsing is, such an index is impossible,
given the MVCC versioning of records (happy to learn I'm wrong).
I'd be curious to know what other people, who've crossed t
the XServe/XRaid comes with FibreChannel
Here some infos:
http://www.apple.com/xserve/raid/architecture.html
http://www.apple.com/xserve/raid/fibre_channel.html
http://www.apple.com/xserve/architecture.html
Ralf Schramm
Am 25.08.2004 um 23:22 schrieb Josh Berkus:
Robert,
Just curious if folks have
we checked a XServe/XRaid system some months ago and
especially the relation price/space/performance was OK
compared to a HP/Intel maschine. Tomorrow I'll try to
find the performance charts on my harddisc and post the
links to the list. You get a huge amount of raid-space
for a good price.
We plan
Coming from the MSSQL world, I'm used to the first step in optimization
to be, choose your clustered index and choose it well.
I see that PG has a one-shot CLUSTER command, but doesn't support
continuously-updated clustered indexes.
What I infer from newsgroup browsing is, such an index is impossib
Two more unusual suggestions:
1. Drop all the indexes and just do sequential scans (full table scans),
aiming as hard as possible to get the whole people table to fit in memory
(size says that should be easy - various ways) - and make sure you're using
8.0 so you have the best cache manager. This
Herve'
> The request takes about 4 seconds ... I have about 1 400 000 records in
> article and 36 000 records in site table ... it's a Bi-Pentium III 933 MHz
> server with 1 Gb memory ... I'm using Postgresql 7.4.5
> For me this result is very very slow I really need a quicker result with
> less t
Guys,
> the XServe/XRaid comes with FibreChannel
I stand corrected. That should help things some; it makes it more of a small
tradeoff between performance and storage size for the drives.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)
Josh Berkus <[EMAIL PROTECTED]> writes:
> Robert,
>
>> Just curious if folks have ever used this for a postgresql server and if
>> they used it with OSX/BSD/Linux. Even if you haven't used it, if you
>> know of something comparable I'd be interested. TIA
>
\> Last I checked Apple was still shippi
Hi,
I'm a little beginner with Tsearch2
I have simples tables like this :
# \d article
Table "public.article"
Column |Type |
Modifiers
+-+---
Robert,
> Just curious if folks have ever used this for a postgresql server and if
> they used it with OSX/BSD/Linux. Even if you haven't used it, if you
> know of something comparable I'd be interested. TIA
Last I checked Apple was still shipping the XServes with SATA drives and a
PROMISE cont
Just curious if folks have ever used this for a postgresql server and if
they used it with OSX/BSD/Linux. Even if you haven't used it, if you
know of something comparable I'd be interested. TIA
http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/72103/wo/oC2xGlPM9M2i3UsLG0f1PaalTlE/0.
Richard Huxton <[EMAIL PROTECTED]> writes:
> Things to check:
> 1. postgresql.conf settings match - different costs could cause this
> 2. statistics on the two columns (trn_patno,trn_old_date) - if they
> differ considerably between systems that would also explain it.
The different estimated row
Mark, Tim,
> select
> pav1.person_id
> from
> person_attributes_vertical pav1
> where
> (pav1.attribute_id = 1
> and pav1.value_id in (2,3))
> or (pav1.attribute_id = 2
> and pav1.value_id in (2,3))
Not the same query, sorry. Daniel's query
David Price wrote:
I have 2 servers both with the exact same data, the same O.S., the same
version of Postgres (7.4.5) and the exact same db schema's (one production
server, one development server). One server is using the correct index for
SQL queries resulting in extremely slow performance, the
I have 2 servers both with the exact same data, the same O.S., the same
version of Postgres (7.4.5) and the exact same db schema's (one production
server, one development server). One server is using the correct index for
SQL queries resulting in extremely slow performance, the other server is
pro
Tom Lane mentioned :
=> Not if you haven't got the RAM to support it :-(
=>
=> Another thing you might look at is ANALYZEing the tables again after
=> you've loaded all the new data. The row-count estimates seem way off
=> in these plans. You might need to increase the statistics target,
=> too,
Hi,
On Aug 25, 2004, at 4:22 AM, Mark Kirkwood wrote:
> select
> pav1.person_id
> from
> person_attributes_vertical pav1
> where
> (pav1.attribute_id = 1
> and pav1.value_id in (2,3))
> or (pav1.attribute_id = 2
> and pav1.value_id in (2,3))
On Aug 25, 2004, at 4:22 AM, Mark Kirkwood wrote:
select
pav1.person_id
from
person_attributes_vertical pav1
where
(pav1.attribute_id = 1
and pav1.value_id in (2,3))
or (pav1.attribute_id = 2
and pav1.value_id in (2,3))
You know..
I
Hi,
We're now getting very much off-topic about configuration of networking, but:
- What is your OS?
- What output do you get when you type 'ping localhost' in any command-prompt?
-Original Message-
[...]
> I tried to put my_ip instead of "localhost" in
> bufmng.c and it seems to work
On 8/25/2004 2:54 AM, my ho wrote:
Tom Lane answered to that question. The code in
question does resolve
"localhost" with getaddrinfo() and then tries to
create and bind a UDP
socket to all returned addresses. For some reason
"localhost" on your
system resolves to an address that is not availabl
Josh Berkus wrote:
Things we've already tried to avoid going over old ground:
1) increasing statistics;
2) increasing sort_mem (to 256MB, which is overkill)
3) testing on 8.0 beta, which does not affect the issue.
At this point I'm looking for ideas. Suggestions, anyone?
with respect to query
Not sure about the overall performance, etc. but I think that in order to collect
statistics you need to set some values in the postgresql.conf config file, to wit:
#---
# RUNTIME STATISTICS
#-
24 matches
Mail list logo
