Tom Lane wrote:
> alphax <[EMAIL PROTECTED]> writes:
>> So, it seems the system column "cmin" is the logical "current version"
>> of that record, isn't it?
>
> No. Have you read
> http://www.postgresql.org/docs/8.2/static/ddl-system-columns.html
>
Yes, I do. But I don't understand the actual mean
Oh - if you do this then make sure that you have the primary key index on
overview too.
Alex
On Jan 14, 2008 12:53 AM, Alex Turner <[EMAIL PROTECTED]> wrote:
> If you combine it with Tom Lane's suggestion - it will go even better,
> something like:
>
> select * from t_documentcontent where _id i
Apparently I was suffering from brain freeze.
sim
Lew wrote:
(attribution restored)
Clodoaldo wrote:
> I don't know if the plan would be the same but this is a bit clearer:
>
> WHERE COALESCE(b.quantity, 0) > COALESCE(b.deliveredsum, 0)
Sim Zacks wrote:
That should be true, but sometimes w
If you combine it with Tom Lane's suggestion - it will go even better,
something like:
select * from t_documentcontent where _id in (select _id from overview where
_id>x order by _id limit 50);
Alex
On Jan 13, 2008 11:59 PM, pepone. onrez <[EMAIL PROTECTED]> wrote:
>
> Thanks Alex
>
> I test yo
Thanks Alex
I test your solution and is realy more faster.
Nested Loop (cost=1743.31..2044.58 rows=50 width=908) (actual time=
101.695..106.178 rows=50 loops=1)
-> HashAggregate (cost=1743.31..1743.31 rows=50 width=108) (actual time=
101.509..101.567 rows=50 loops=1)
-> Subquery Sca
Here is a table I threw together to demonstrate the approximate speed of a
materialized view in this case:
trend=# explain analyze select property_id from overview order by
property_id limit 50 offset 5;
QUERY
PLAN
--
If you have to access the data this way (with no where clause at all - which
sometimes you do) then I have already provided a solution that will work
reasonably well. If you create what is essentially a materialized view of
just the id field, the sequence scan will return much fewer pages than whe
Sorry Alex i forget mention that i have setscan of in my last test.
now I have set seqscan on and indexscan on and added order by _id
The table has an index in the _id field
CREATE INDEX i_documentcontent_document
ON t_documentcontent
USING btree
(_document);
The database was rencently v
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> On Jan 13, 2008 8:58 PM, pepone. onrez <[EMAIL PROTECTED]> wrote:
>> t_documentcontent._id AS _id
>> FROM t_documentcontent LIMIT 50 OFFSET 8
> with no order by, and possibly no index on t_documentcontent._id,
> there's no choice but a seq scan.
M
On Jan 13, 2008 8:58 PM, pepone. onrez <[EMAIL PROTECTED]> wrote:
> I have this query in a table with 150 thowsand tuples and it takes to long
>
> t_documentcontent._id AS _id
> FROM t_documentcontent LIMIT 50 OFFSET 8
>
> here is the explain output
>
> "Limit (cost= 100058762.30..1000
If you haven't already, make sure you've done a vacuum full recently. When
in doubt, pg_dump the db, and reload it, and see if that helps, but this
works for me:
create table overview as select _id from t_documentcontent;
alter table overview add constraint overview_pkey primary key (_id);
selec
I have this query in a table with 150 thowsand tuples and it takes to long
t_documentcontent._id AS _id
FROM t_documentcontent LIMIT 50 OFFSET 8
here is the explain output
"Limit (cost=100058762.30..100058799.02 rows=50 width=58) (actual time=
19433.474..19433.680 rows=50 loops=1)"
"Ken Winter" <[EMAIL PROTECTED]> writes:
> I need to understand, in as much detail as possible, the results that will
> occur when pg_restore restores from an archive file into a target database
> that already contains some database objects. I can't find any reference
> that spells this out. (The
On 1/11/08, alphax <[EMAIL PROTECTED]> wrote:
> I want to determines a given record which visible to current transaction
> whether or not be updated after some time point, that time point is
> indicated by aother transaction id started and committed in past time.
I'm not sure I understand, but ma
I need to understand, in as much detail as possible, the results that will
occur when pg_restore restores from an archive file into a target database
that already contains some database objects. I can't find any reference
that spells this out. (The PG manual isn't specific enough.)
Instead of ju
"Satch Jones" <[EMAIL PROTECTED]> writes:
> Hello - I can't get tsearch2 running in a long-functioning instance of
> PostgreSQL 8.1.9 on Fedora Core 5, and could use some help.
Rather than trying to compile it yourself, why don't you just install
the postgresql-contrib RPM that goes with the postg
Hello - I can't get tsearch2 running in a long-functioning instance of
PostgreSQL 8.1.9 on Fedora Core 5, and could use some help.
When I place the tsearch2 source files under the contrib folder in a
standard Fedora Core 5 postgres install (/usr/share/pgsql/contrib) and run
make, I get the foll
Hi,
I have a query that takes 0.450 ms. Its a xml query. Is that a good time
for a query? If a have multiple connections on the database, will this time
makes my db slow? How much time is good for a xml query?
Thanks
On Sun, January 13, 2008 7:25 pm, Tom Lane wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
>> On Sun, Jan 13, 2008 at 08:40:34AM +0200, henry wrote:
>>> lsof doesn't tell me what's talking to PG through /tmp/.s.PGSQL.5432
>>> either. Maybe I'm not understanding exactly how /tmp/.s.PG
alphax <[EMAIL PROTECTED]> writes:
> So, it seems the system column "cmin" is the logical "current version"
> of that record, isn't it?
No. Have you read
http://www.postgresql.org/docs/8.2/static/ddl-system-columns.html
regards, tom lane
---(end
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Sun, Jan 13, 2008 at 08:40:34AM +0200, henry wrote:
>> lsof doesn't tell me what's talking to PG through /tmp/.s.PGSQL.5432
>> either. Maybe I'm not understanding exactly how /tmp/.s.PGSQL.5432 is
>> used - what would connect to PG via a doma
Michael Meskes wrote:
On Fri, Jan 11, 2008 at 11:51:08PM +, Peter Wilson wrote:
I've just tried compiling our project against the 8.3RC1 code. This is
the first time I've tried any release of 8.3.
...
crbembsql.pgC:254: error: invalid conversion from `int' to `ECPG_statement_type'
crbembsql
On Fri, Jan 11, 2008 at 11:51:08PM +, Peter Wilson wrote:
> I've just tried compiling our project against the 8.3RC1 code. This is
> the first time I've tried any release of 8.3.
> ...
> crbembsql.pgC:254: error: invalid conversion from `int' to
> `ECPG_statement_type'
> crbembsql.pgC:254: er
Marko Kreen wroted:
By the way, Can I think that the value of system column "ctid" of an
record is the logical "current version" of that record, and used to
compare with txid returned by "FUNCTIONS-TXID-SNAPSHOT"?
No, it is just physical location of the row.
Thanks, I just done some sim
On Sun, Jan 13, 2008 at 08:40:34AM +0200, henry wrote:
> > This is all irrelevant to your real problem, to judge by the rest of
> > the thread, but I'm curious.
>
> I did in fact find a leak in long-lived procs (some of which can run for
> days) - but squashing that did not make my problem go away
> I don't know if the plan would be the same but this is a bit clearer:
>
> WHERE COALESCE(b.quantity, 0) > COALESCE(b.deliveredsum, 0)
That should be true, but sometimes we get deliveries of greater quantity then
we ordered.
I just want to know the times when I haven't gotten the complete order
2008/1/13, Sim Zacks <[EMAIL PROTECTED]>:
> How would you rewrite something like:
>WHERE (COALESCE(b.quantity, 0) - COALESCE(b.deliveredsum, 0)) > 0;
> I could write:
> where case when b.quantity is null then 0 else b.quantity end - case when
> b.deliveredsum is null then 0 else b.deliveredsum
On Sat, January 12, 2008 6:50 pm, Tom Lane wrote:
> "henry" <[EMAIL PROTECTED]> writes:
>> I have tried setting tcp_keepalives_idle = 120 (eg), then restarting PG,
>> but SHOW ALL; shows tcp_keepalives_idle=0 (ignoring my setting).
>
> Just FYI, this is the expected behavior on platforms where th
28 matches
Mail list logo
