Dado,
> I'm not sure if I worded the subject right, but my problem is this:
>
> I have a few entries in one table. Each row is the parent of many
> entries in a second table.
> In the second table I have a lot of entries referencing the entries
> on
> the first table.
> So far so good. Basic f
I'm not sure if I worded the subject right, but my problem is this:
I have a few entries in one table. Each row is the parent of many
entries in a second table.
In the second table I have a lot of entries referencing the entries on
the first table.
So far so good. Basic foreign key thing.
The
David,
You will no doubt hear later from the tuning experts on the list.
However, let me save everybody some time by verifying some basics:
1. When you restructured the database, you ran VACUUM ANALYZE on the new
database (pacs)?
2. You said that you "eliminated the indexes" because they weren'
Richard,
> > Josh - if I try and do OFFSET at the same time (presumably it's the
> same
> > change) do you fancy acting as a sanity test site?
>
> What am I talking about - OFFSET is going to be parsed by the SQL
> parser not
> the plpgsql parser.
Not so, not so!
Try the following two PL/pgSQL
What version are you using? (dbPG95GetIndex?)
On Thu, 19 Jul 2001, David M. Richter wrote:
> Hallo !
>
> I want to tune a database. There a many redundant datas in the database
> , because of all the relations were consider as n:m relations. But the
> most of them are 1:n Relations. So my appr
From: "Richard Huxton" <[EMAIL PROTECTED]>
> False Laziness perhaps (spot my Perl background)
>
> OK - stick me down for having a look at it. Had a quick peek and I think
> it's within my abilities. Give me a couple of weeks, because I haven't
> looked at a YACC file since my university days (gra
Hallo !
I want to tune a database. There a many redundant datas in the database
, because of all the relations were consider as n:m relations. But the
most of them are 1:n Relations. So my approach was to cut the
redundancies to get more performance. But .. happens!
The query with the 3 tables i
From: "Tom Lane" <[EMAIL PROTECTED]>
> "Richard Huxton" <[EMAIL PROTECTED]> writes:
> > Don't know why the parser for RAISE doesn't like string concat.
>
> Laziness ;-). Someone should fix plpgsql so that RAISE does take
> expressions, not just literals and simple variables. It probably
> would
