Szűcs,
Thanks for your suggestion, I
guess there is more than one way to attack the problem.
I ended up using a trick with limit to get the next
row ...
select (b.gc_minor- a.gc_minor), (b.gc_major-
a.gc_major)from jam_trace_sys a join jam_trace_sys b on(b.seq_no =
(select c.seq_no
Relating to this. If anyone can find govt or other free db's and
convert them into pgsql format, I will host them on the dbsamples page.
The dbsamples are _really_ popular!
Chris
Scott Marlowe wrote:
On Fri, 2006-02-17 at 10:51, Ron wrote:
I assume we have such?
Depends on what you wanna
Here's a simplified version of the schema:
Table A has an ID field, an observation date, and other stuff. There are about
20K IDs and 3K observations per ID. Table B has a matching ID field, minimum
and maximum dates, a code, and other stuff, about 0-50 records per ID. For a
given ID, the dates
Not really, but you can check out the sample databases project:
http://pgfoundry.org/projects/dbsamples/
Chris
Ron wrote:
I assume we have such?
Ron
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Emil Briggs <[EMAIL PROTECTED]> writes:
> Does any know why the query behaves like this? Does it have anything to
> do with the OR statements in the where clause spanning two different tables?
Exactly.
> SELECT DISTINCT a.account_id, l.username, a.status, a.company, a.fax_num,
> a.primary_phone
Fredrik Olsson <[EMAIL PROTECTED]> writes:
> -> Seq Scan on t_entities (cost=0.00..1.49 rows=7 width=4)
> (actual time=404.539..409.302 rows=2 loops=1)
> Filter: ((haveaccess(createdby, responsible, "class",
> false) OR CASE WHEN (partof = 'contacts'::name) THEN
> ischildof(
The following query runs much slower than I would have expected. I ran it
through EXPLAIN ANALYZE (results included after) and I don't understand why
the planner is doing what it is. All of the columns from the WHERE part of
the query are indexed and the indexes are being used. The number of r
Tom Lane skrev:
Fredrik Olsson <[EMAIL PROTECTED]> writes:
I have some quite huge queries, inside functions, so debugging is kind
of hard. But I have located the query that for some reason gets 4 times
as slow after an analyze.
Could we see EXPLAIN ANALYZE output for these cases, not
