Ross J. Reedstrom [EMAIL PROTECTED] writes:
In the new schema, the same thing is:
SELECT * from content where 42 = ANY (authors);
Works fine, but for the life of me I can't find nor figure out how to
build an index that will be used to speed this along. Any ideas?
Well that's basically
Brian Hirt wrote:
I've been using the adaptec ZCR raid cards in our servers for a while
now, mostly small systems with 3 or 6 disks, and we've been very happy
with them. However, we're building a new DB machine with 14 U320 15K
SCA drives, and we've run into a performance bottlenkeck with
Josh Berkus wrote:
Herve'
I forgot to ask about your hardware. How much RAM, and what's your disk
setup? CPU?
sort_mem = 512000
Huh? Sort_mem is in K. The above says that you've allocated 512MB sort
mem. Is this process the *only* thing going on on the machine?
And also is not
Hervé Piedvache wrote:
Josh,
Le mardi 13 Juillet 2004 19:10, Josh Berkus a écrit :
What can I do to get better results ?? (configuration option, and/or
hardware update ?)
What can I give you to get more important informations to help me ?
1) What PostgreSQL version are you using?
v7.4.3
2)
Hello --
To increase query (i.e. select) performance, we're trying to get
postgres to use an index based on a timestamp column in a given table.
Event-based data is put into this table several times a minute, with the
timestamp indicating when a particular row was placed in the table.
The
Ross wrote:
Hi all -
I've got a schema I'm working on modifying, nad I need some help
getting
the best performance out. The orginal schema has a many to many
linkage
between a couple tables, using a two column linkage table. This is
used
to represent groups of people and their relationship to
Harmon S. Nine wrote:
monitor=# explain analyze select * from eventtable where timestamp
CURRENT_TIMESTAMP - INTERVAL '10 minutes';
QUERY PLAN
Try
SELECT * FROM eventtable where timestamp BETWEEN (CURRENT_TIMESTAMP -
INTERVAL '10
VACUUM FULL ANALYZE every 3 hours seems a little severe. You will
probably be be served just as well by VACUUM ANALYZE. But you probably
don't need the VACUUM part most of the time. You might try doing an
ANALYZE on the specific tables you are having issues with. Since
ANALYZE should be
On Mon, 26 Jul 2004, Harmon S. Nine wrote:
However, we can't get the planner to do an timestamp-based index scan.
Anyone know what to do?
I'd wonder if the type conversion is causing you problems.
CURRENT_TIMESTAMP - INTERVAL '10 minutes' is a timestamp with time zone
while the column is
Matthew T. O'Connor [EMAIL PROTECTED] writes:
VACUUM FULL ANALYZE every 3 hours seems a little severe.
If rows are only deleted once a day, that's a complete waste of time,
indeed.
I'd suggest running a plain VACUUM just after the deletion pass is done.
ANALYZEs are a different matter and
On Mon, 2004-07-26 at 08:20, Gaetano Mendola wrote:
Herv Piedvache wrote:
SNIP
sort_mem = 512000
This is too much, you are instructing Postgres to use 512MB
for each backend ( some time each backend can use this quantity
more then one )
agreed. If any one process needs this much sort
THAT WAS IT!!
Thank you very much.
Is there a way to change the type of "CURRENT_TIMESTAMP" to "timestamp
without time zone" so that casting isn't needed?
BTW, isn't this a bug?
-- Harmon
Stephan Szabo wrote:
On Mon, 26 Jul 2004, Harmon S. Nine wrote:
However, we can't get
On Mon, Jul 26, 2004 at 02:27:20AM -0400, Greg Stark wrote:
Ross J. Reedstrom [EMAIL PROTECTED] writes:
In the new schema, the same thing is:
SELECT * from content where 42 = ANY (authors);
Works fine, but for the life of me I can't find nor figure out how to
build an index that
SELECT * from content where 42 = ANY (authors);
Postgres does have a way to do what you ask, though. It involves GiST
indexes and the operators from the contrib/intarray directory from the
Postgres source.
I have tried to use these indexes, and the performance was very good. It
can be
Ross J. Reedstrom [EMAIL PROTECTED] writes:
These groups _really are_ ideal for Joe Conway's work on arrays: we need
ordered vectors, so we'd be sorting all the time, otherwise. They're
static, and they're read only. The one thing they're not is fixed, known
size (Sorry Merlin). They work
Greg Stark [EMAIL PROTECTED] writes:
I would be curious to know how it goes. My own project uses
denormalized sets stored as arrays as well, though in my case they're
precalculated from the fully normalized data. I tried to use GiST
indexes but ran into problems combining the btree-GiST code
Hi,
How about changing:
CURRENT_TIMESTAMP - INTERVAL '10 minutes'
to
'now'::timestamptz - INTERVAL '10 minutes'
It seems to me that Postgres will treat it as
a constant.
Thanks,
--- Tom Lane [EMAIL PROTECTED] wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
VACUUM FULL ANALYZE every 3
Litao Wu [EMAIL PROTECTED] writes:
How about changing:
CURRENT_TIMESTAMP - INTERVAL '10 minutes'
to
'now'::timestamptz - INTERVAL '10 minutes'
It seems to me that Postgres will treat it as
a constant.
Yeah, that works too, though again it might burn you if used inside a
function or
It seems to me that Postgres will treat it as
a constant.
Yeah, that works too, though again it might burn you if used inside a
function or prepared statement. What you're doing here is to push the
freezing of the now value even further upstream, namely to initial
parsing of the command.
What I
Tom Lane [EMAIL PROTECTED] writes:
I still don't really know why it failed, but after two days building the
index I gave up.
Sounds like a bug to me. Could you put together a test case?
At the time I contacted one of the GiST authors and we went over things for a
while. They diagnosed
20 matches
Mail list logo
