Seb wrote:
> On Mon, 18 Jan 2010 08:59:56 +1100,
> Chris wrote:
>
>>> o Should all foreign keys have an index?
>
>> Not necessarily, you might just want the db to enforce the restriction
>> but not actually use the data in it. For example, keep a userid (and
>> timestamp) column of the last pers
On Mon, 18 Jan 2010 08:59:56 +1100,
Chris wrote:
>> o Should all foreign keys have an index?
> Not necessarily, you might just want the db to enforce the restriction
> but not actually use the data in it. For example, keep a userid (and
> timestamp) column of the last person to update a row. You
Seb wrote:
Hi,
I have some views and queries that take a bit too long to return, so
perhaps some judicious indexes might help, but I don't know much about
how to use them. The PostgreSQL manual has a good section on indexes,
but I can't find guidance on (unless I missed something):
o How to de
> The computed cost of using the index was a factor of 10 higher which I
presume is why the query planner wasn't
> using the index, but it ran in half the time
Have you tried playing with the random_page_cost parameter? The default is
4. Try:
set random_page_cost = 1;
in psql to alter it for th
"David Witham" <[EMAIL PROTECTED]> writes:
> Does this make it a "wide" table?
Nope. A rough estimate is that your rows will be about 160 bytes wide,
which means you can fit about 50 per 8K page. So a query that needs to
select 8% of the table will *on average* need to hit about 4 rows per
page.
e.
I hope this makes sense. Does it help any?
Thanks,
David
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 18 February 2004 16:10
To: David Witham
Cc: [EMAIL PROTECTED]
Subject: Re: [SQL] Indexes and statistics
"David Witham" <[EMAIL PROTECTED]&g
"David Witham" <[EMAIL PROTECTED]> writes:
> One of the customers is quite large (8.3% of the records):
Hmm. Unless your rows are quite wide, a random sampling of 8.3% of the
table would be expected to visit every page of the table, probably
several times. So the planner's cost estimates do not
From: "Stephan Szabo" <[EMAIL PROTECTED]>
> You need to have made the database in C locale in order to get index scans
> from LIKE. I think that's mentioned in the Localization section of the
> admin guide, but I could be remembering that wrong.
Thanks very much Stephan. Indeed it's in Admin G
On Sat, 13 Jul 2002, Julian Scarfe wrote:
> From: "Stephan Szabo" <[EMAIL PROTECTED]>
>
> > You need to have made the database in C locale in order to get index scans
> > from LIKE. I think that's mentioned in the Localization section of the
> > admin guide, but I could be remembering that wrong
On Sat, 13 Jul 2002, Julian Scarfe wrote:
> I've noticed a difference in behaviour between a server running version 6.x
> and one running 7.2.1 in use of indexes with LIKE.
>
> With an index on foo,
>
> WHERE foo LIKE 'bar%'
>
> uses the index (as I would expect it to) on the 6.x box, but uses a
I'm going to write a function in C that parses XML. Is there any way
to index the output of this function? I've got 10,000,000 rows that
contain XML data and I need to efficiently find the ones that contain
the proper keys. I tried pulling the values I want from the data and
putting it in its
On Sat, 13 Oct 2001 14:17:48 GMT, "Aasmund Midttun Godal" <[EMAIL PROTECTED]>
wrote:
> On Fri, 12 Oct 2001 19:33:46 -0700 (PDT), Stephan Szabo
><[EMAIL PROTECTED]> wrote:
> Well, then another question; will a function be only evaluated once inside a query
>with the specific arguments?
>
> i.e.
On Fri, 12 Oct 2001, Aasmund Midttun Godal wrote:
> Can someone shed some light on as to how the indexes actually work?
>
> I want to index the results of a function, the function does a whole
> lot of different selects on different tables. Will the database know
> when to update the index.
AFA
13 matches
Mail list logo
