I know you will shoot me down, but...
Why is there an entry in the index for a row if the row is not valid?
Wouldn't it be better for the index entry validity to track the row validity.
If a particular data value for a query (join, where etc.) can be satisfied
by the index entry itself this wou
[EMAIL PROTECTED] writes:
> ... Wouldn't the most efficient plan be to scan the index regardless
> of crm_id because the only columns needed are in the index?
No. People coming from other databases often have the misconception
that queries can be answered by looking only at an index. That is nev
I am going to use them as primary key of the table, so I'll surely need
them unique :)
Eduoardo, I REALLY suggest you don't use them at all. You should make a
primary key like this:
CREATE TABLE blah (
id SERIAL PRIMARY KEY,
...
);
Also note that by default, OIDs are NOT dumped by pg_dump.
Vitaly,
I'm afraid that your helper on DevShed is right; 7.5 for Windows is still in
development, we've not even *started* to check it for performance yet.
Since the Merge Join is taking 90% of your query time, I might suggest
increasing shared_buffers and sort_mem to see if that helps.
--
On Tue, 2004-04-27 at 17:27, Vitaly Belman wrote:
> Hello pgsql-performance,
>
> I discussed the whole subject for some time in DevShed and didn't
> achieve much (as for results). I wonder if any of you guys can help
> out:
>
> http://forums.devshed.com/t136202/s.html
You're taking the w
Hi,
You can try some variation:
SELECT
book_id
FROM
bookgenres, genre_children
WHERE
bookgenres.genre_id = genre_children.genre_child_id AND
genre_children.genre_id = 1
GROUP BY book_id
LIMIT 10
The next works if the 'genre_child_id' is UNIQUE on the 'genre_children'
table.
SELEC
Vitaly Belman wrote:
Hello pgsql-performance,
I discussed the whole subject for some time in DevShed and didn't
achieve much (as for results). I wonder if any of you guys can help
out:
http://forums.devshed.com/t136202/s.html
So cutting and pasting:
- SCHEMA -
CREATE TABLE bv_bookge
I am going to use them as primary key of the table, so I'll surely need
them unique :)
thank you for you help
Edoardo
Dave Cramer ha scritto:
Edoardo,
Are you using them for referential integrity? If so you would be wise to
use sequences instead.
Christopher: yes you are correct, I wasn't sur
Hello pgsql-performance,
I discussed the whole subject for some time in DevShed and didn't
achieve much (as for results). I wonder if any of you guys can help
out:
http://forums.devshed.com/t136202/s.html
Regards,
Vitaly Belman
ICQ: 1912453
AIM: VitalyB1984
MSN: [EMAIL PROTECTED]
Dave,
> But... you need a baseline first.
A baseline on CS? I have that
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Josh,
I think you can safely increase by orders of magnitude here, instead of
by +100, my wild ass guess is that the sweet spot is the spin time
should be approximately the time it takes to consume the resource. So if
you have a really fast machine then the spin count should be higher.
Also you
On Mon, 26 Apr 2004, Rob Fielding wrote:
> scott.marlowe wrote:
> > On Fri, 23 Apr 2004, Chris Hoover wrote:
> >
> >
> >>DB's on Powervaults 220S using raid 5 (over 6 disks)
> >
> >
> > What controller is this, the adaptec? We've found it to be slower than
> > the LSI megaraid based controll
Dave,
> Are you testing this with Tom's code, you need to do a baseline
> measurement with 10 and then increase it, you will still get lots of cs,
> but it will be less.
No, that was just a test of 1000 straight up.Tom outlined a method, but I
didn't see any code that would help me find a be
Hi,
I came across a very intriguing thing:
I had to join two tables and in both tables I wanted to restrict the
result set by some (text/varchar) attributes.
Here is an example:
Table "item" # 147 000 entries
Column | Type | Modifiers
---+-
Edoardo,
Are you using them for referential integrity? If so you would be wise to
use sequences instead.
Christopher: yes you are correct, I wasn't sure if that is what he was
doing.
Dave
On Tue, 2004-04-27 at 11:01, Christopher Kings-Lynne wrote:
> > AFAIK, oids aren't used for anything inter
AFAIK, oids aren't used for anything internally, so duplicates don't
really matter. Besides, what would you do about duplicate oid's ?
If he's using them _externally_, then he does have to worry about
duplicates.
Chris
---(end of broadcast)---
TIP 5
Hi,
You should try the next queries:
select support_person_id from ticket_crm_map where crm_id = 7 GROUP BY
support_person_id;
select support_person_id from ticket_crm_map where crm_id = 1 GROUP BY
support_person_id;
It can use the 'ticket_crm_map_crm_id_suppid' index.
Generally the Postgres u
On Wed, 21 Apr 2004 10:01:30 -0700, Qing Zhao <[EMAIL PROTECTED]>
wrote:
>I have recently configured my PG7.3 on a G5 (8GB RAM) with
>shmmax set to 512MB and shared_buffer=5, sort_mem=4096
>and effective cache size = 1. It seems working great so far but
>I am wondering if I should make eff
AFAIK, oids aren't used for anything internally, so duplicates don't
really matter. Besides, what would you do about duplicate oid's ?
The best suggestion is of course his last, don't use them.
On Mon, 2004-04-26 at 22:48, Christopher Kings-Lynne wrote:
> > I am using the oid of the table as the
19 matches
Mail list logo
