On Fri, 1 Aug 2003 18:17:17 -0300, "Fernando Papa" <[EMAIL PROTECTED]>
wrote:
> AND cont_publicacion.fecha_publicacion = (SELECT
>max(cp1.fecha_publicacion)
> FROM cont_publicacion cp1
> WHERE cp1.id_instalacion =
>cont_publicacion.id_instalacion
>
Sorry Chris... a little slower...
esdc=> EXPLAIN ANALYZE
SELECT
cont_contenido.id_contenido
,cont_contenido.pertenece_premium
,cont_contenido.Titulo_esp as v_sufix
,cont_contenido.url_contenido
,cont_contenido.tipo_acceso
,cont_contenido.id_sbc
,cont_contenido.cant_vistos
,cont_conteni
Hi Josh... a little worse time:
EXPLAIN ANALYZE
SELECT
cont_contenido.id_contenido
,cont_contenido.pertenece_premium
,cont_contenido.Titulo_esp as v_sufix
,cont_contenido.url_contenido
,cont_contenido.tipo_acceso
,cont_contenido.id_sbc
,cont_contenido.cant_vistos
,cont_contenido.cant_vo
I create the index, but doesn't help too much:
QUERY
PLAN
---
Title: Mensaje
Hi
Volker!!! I think you're right. Look at times:
QUERY
PLAN
-
On Mon, 4 Aug 2003 12:02:46 -0300, "Fernando Papa" <[EMAIL PROTECTED]>
wrote:
>FROM
>cont_contenido
>,juegos_config
>,cont_publicacion
>,(SELECT max(cp1.fecha_publicacion) as max_pub
> --change here
>
Err... you're right... one of us say the same thing when I show the
Volker mail...
-Mensaje original-
De: Manfred Koizar [mailto:[EMAIL PROTECTED]
Enviado el: lunes, 04 de agosto de 2003 12:17
Para: Fernando Papa
CC: Volker Helm; [EMAIL PROTECTED]
Asunto: Re: [PERFORM] I can't wait too mu
Hello,
Note: there is a SQL question way at the bottom of this narrative :-)
Last week I asked about doing substring operations on very long strings
(>10 million characters). I was given a suggestion to use EXTERNAL
storage on the column via the ALTER TABLE ... SET STORAGE command. In
one test
Scott Cain <[EMAIL PROTECTED]> writes:
> At least this appears to work and is much faster, completing substring
> operations like above in about 0.27 secs (that's about two orders of
> magnitude improvement!)
I find it really, really hard to believe that a crude reimplementation
in plpgsql of the
On Monday 04 August 2003 16:25, Scott Cain wrote:
[snip]
> In an effort to find the best way to do this operation, I decided to
> look at what is my "worst case" scenario: the DNA sequence for human
> chromosome 1, which is about 250 million characters long (previous
> strings where about 20 millio
On Mon, 2003-08-04 at 11:55, Richard Huxton wrote:
> On Monday 04 August 2003 16:25, Scott Cain wrote:
> [snip]
> > [snip]
>
> You might want some checks to make sure that smin < smax, otherwise looks like
> it does the job in a good clean fashion.
Good point--smin < smax generally by virtue of
On 4 Aug 2003 at 12:14, Scott Cain wrote:
> I forgot about searching--I suspect that application is why I faced
> opposition for shredding in my schema development group. Maybe I should
> push that off to the file system and use grep (or BLAST). Otherwise, I
> could write a function that would se
On Mon, 2003-08-04 at 11:53, Tom Lane wrote:
> Scott Cain <[EMAIL PROTECTED]> writes:
> > At least this appears to work and is much faster, completing substring
> > operations like above in about 0.27 secs (that's about two orders of
> > magnitude improvement!)
>
> I find it really, really hard to
> > 2. If you want to search for a sequence you'll need to deal with the case
> > where it starts in one chunk and ends in another.
>
> I forgot about searching--I suspect that application is why I faced
> opposition for shredding in my schema development group. Maybe I should
> push that off to t
On 01 Aug 2003 11:04:10 -0700, Jenny Zhang <[EMAIL PROTECTED]> wrote:
>A sample OSDL-DBT3 test result report can be found at:
>http://khack.osdl.org/stp/276912/
>
>Your comments are welcome,
| effective_cache_size | 1000
With 4GB of memory this is definitely too low and *can* (note that
On Mon, 4 Aug 2003, Manfred Koizar wrote:
> On 01 Aug 2003 11:04:10 -0700, Jenny Zhang <[EMAIL PROTECTED]> wrote:
> >A sample OSDL-DBT3 test result report can be found at:
> >http://khack.osdl.org/stp/276912/
> >
> >Your comments are welcome,
>
> | effective_cache_size | 1000
>
> With
On Mon, 4 Aug 2003, Manfred Koizar wrote:
> On 01 Aug 2003 11:04:10 -0700, Jenny Zhang <[EMAIL PROTECTED]> wrote:
> >A sample OSDL-DBT3 test result report can be found at:
> >http://khack.osdl.org/stp/276912/
> >
> >Your comments are welcome,
>
> | effective_cache_size | 1000
>
> With
On 4 Aug 2003 at 15:33, Manfred Koizar wrote:
> On 01 Aug 2003 11:04:10 -0700, Jenny Zhang <[EMAIL PROTECTED]> wrote:
> >A sample OSDL-DBT3 test result report can be found at:
> >http://khack.osdl.org/stp/276912/
> >
> >Your comments are welcome,
I could not get postgresql .conf so I will combine
I was play with nested loops, and I found this:
Original explain:
Limit (cost=9.75..9.76 rows=1 width=479) (actual
time=436858.90..436858.93 rows=8 loops=1)
-> Sort (cost=9.75..9.76 rows=1 width=479) (actual
time=436858.88..436858.89 rows=8 loops=1)
Sort Key: cont_publicacion.fe
On Mon, Aug 04, 2003 at 15:05:08 -0600,
"Valsecchi, Patrick" <[EMAIL PROTECTED]> wrote:
> Sir,
>
> I did a search with the "index" keyword on the mailing list archive and it did come
> with no result. Sorry if it's a known bug.
It isn't a bug. It is a design trade off. The database has no spe
"Fernando Papa" <[EMAIL PROTECTED]> writes:
>-> Nested Loop (cost=0.00..1828.46 rows=1 width=367)
> (actual time=7525.51..436843.27 rows=40 loops=1)
> Join Filter: (("inner".id_contenido =
> "outer".id_contenido) AND ("inner".id_instalacion =
> "outer".id_inst
Thanks Tom. I vaccumed full every night. Now I drop function index and
change the upper. Nothing change (I know, total time rise because we are
doing other things on database now). But you can see, if was any
performace gain i didn't see. Actually I get better results when I
disable nested loops o
"Fernando Papa" <[EMAIL PROTECTED]> writes:
> Thanks Tom. I vaccumed full every night. Now I drop function index and
> change the upper. Nothing change (I know, total time rise because we are
> doing other things on database now).
> -> Seq Scan on cont_publicacion
> (cost=0.0
On Mon, 04 Aug 2003 16:10:18 +0200, I wrote:
>SELECT DISTINCT ON (
>cp.id_instalacion,
>cp.id_contenido,
>cp.generar_vainilla,
>cp.fecha_publicacion
> )
Cut'n'paste error! fecha_publicacion should no
Scott Cain wrote:
On Mon, 2003-08-04 at 11:53, Tom Lane wrote:
I find it really, really hard to believe that a crude reimplementation
in plpgsql of the TOAST concept could beat the built-in implementation
at all, let alone beat it by two orders of magnitude.
Either there's something unrealistic abo
Thanks all for your feedback.
I think I should explain more about how to use this test kit.
The main purpose of putting the test kit on Scalability Test
Platform(STP) is that testers can run the workload against the database
with different parameters and Linux kernels to see performance
differen
On Mon, 2003-08-04 at 09:39, Shridhar Daithankar wrote:
> On 4 Aug 2003 at 15:33, Manfred Koizar wrote:
>
> > On 01 Aug 2003 11:04:10 -0700, Jenny Zhang <[EMAIL PROTECTED]> wrote:
> > >A sample OSDL-DBT3 test result report can be found at:
> > >http://khack.osdl.org/stp/276912/
> > >
> > >Your com
On 4 Aug 2003, Jenny Zhang wrote:
> On Mon, 2003-08-04 at 06:33, Manfred Koizar wrote:
> > | effective_cache_size | 1000
> >
> > With 4GB of memory this is definitely too low and *can* (note that I
> > don't say *must*) lead the planner to wrong decisions.
> >
> I changed the default t
28 matches
Mail list logo
