On Wednesday 08 June 2011 19:47, t...@fuzzy.cz wrote:
Have you tried to create a composite index on those two columns? Not sure
if that helps but I'd try that.
Tomas
This finally works well enough
CREATE TABLE tdiag (
diag_id integer DEFAULT nextval('diag_id_seq'::text),
If I had set the primary key to (diag_id, create_time) would simple
queries on
diag_id still work well i.e.
select * from tdiag where diag_id = 1234;
Yes. IIRC the performance penalty for using non-leading column of an index
is negligible. But why don't you try that on your own - just run
On Wed, Jun 8, 2011 at 7:08 AM, anthony.ship...@symstream.com wrote:
What seems odd to me is that the only difference between the two is the limit
clause
Why would that seem odd?
Of course optimally executing a plan with limit is a lot different
than one without.
Just... why are you sorting
What seems odd to me is that the only difference between the two is the
limit
clause:
select * from tdiag where (create_time = '2011-06-03
09:49:04.00+0' and create_time '2011-06-06 09:59:04.00+0') order
by
diag_id limit 1;
select * from tdiag where (create_time = '2011-06-03
On Wednesday 08 June 2011 17:39, Claudio Freire wrote:
Of course optimally executing a plan with limit is a lot different
than one without.
I imagined that limit just cuts out a slice of the query results.
If it can find 8 rows in 0.5 seconds then I would have thought that
returning just
2011/6/8 anthony.ship...@symstream.com:
On Wednesday 08 June 2011 17:39, Claudio Freire wrote:
Of course optimally executing a plan with limit is a lot different
than one without.
I imagined that limit just cuts out a slice of the query results.
If it can find 8 rows in 0.5 seconds then
On Wednesday 08 June 2011 18:39, Pavel Stehule wrote:
if you use FOR statement, there should be a problem in using a
implicit cursor - try to set a GUC cursor_tuple_fraction to 1.0.
Alas this is mammoth replicator, equivalent to PG 8.3 and it doesn't have that
parameter.
--
Anthony Shipman
On Wednesday 08 June 2011 17:39, Claudio Freire wrote:
Of course optimally executing a plan with limit is a lot different
than one without.
I imagined that limit just cuts out a slice of the query results.
If it can find 8 rows in 0.5 seconds then I would have thought that
returning
Hello
2011/6/8 anthony.ship...@symstream.com:
On Wednesday 08 June 2011 18:39, Pavel Stehule wrote:
if you use FOR statement, there should be a problem in using a
implicit cursor - try to set a GUC cursor_tuple_fraction to 1.0.
Alas this is mammoth replicator, equivalent to PG 8.3 and it
Version: PostgreSQL 8.3.5 (mammoth replicator)
Schema:
CREATE TABLE tdiag (
diag_id integer DEFAULT nextval('diag_id_seq'::text),
create_time timestamp with time zone default now(), /* time this
record
was created */
diag_time timestamp with time zone
Hello
did you run a ANALYZE statement on table tdiag? A statistics are
absolutelly out.
Regards
Pavel Stehule
2011/6/7 anthony.ship...@symstream.com:
Version: PostgreSQL 8.3.5 (mammoth replicator)
Schema:
CREATE TABLE tdiag (
diag_id integer DEFAULT
Version: PostgreSQL 8.3.5 (mammoth replicator)
Schema:
CREATE TABLE tdiag (
diag_id integer DEFAULT nextval('diag_id_seq'::text),
create_time timestamp with time zone default now(), /* time this
record
was created */
diag_time timestamp with time zone
Version: PostgreSQL 8.3.5 (mammoth replicator)
Schema:
CREATE TABLE tdiag (
diag_id integer DEFAULT nextval('diag_id_seq'::text),
create_time timestamp with time zone default now(), /* time
this
record
was created */
diag_time timestamp
On Wednesday 08 June 2011 02:40, t...@fuzzy.cz wrote:
Hi,
why are you reposting this? Pavel Stehule already recommended you to run
ANALYZE on the tdiag table - have you done that? What was the effect?
The mailing list system hiccupped and I ended up with two posts.
VACUUM ANALYZE was done,
14 matches
Mail list logo
