I have a query which get's data from a single table.
When I try to get data from for an RFQ which has around 5000 rows, it is breaking off at 18th row.
If i reduce some columns , then it returns all the rows and not so slow.
I have tried with different sets of column and there is no pattern base
Qing Zhao <[EMAIL PROTECTED]> writes:
> I have a query which get's data from a single table.
> When I try to get data from for an RFQ which has around 5000 rows, it
> is breaking off at 18th row.
> If i reduce some columns , then it returns all the rows and not so slow.
What client-side softwar
Qing Zhao <[EMAIL PROTECTED]> writes:
> It's not through one client. I am using JDBC. But the same things
> happen when I use client like psql.
That's really hard to believe. Can you provide a reproducible test
case?
regards, tom lane
---(end of
Tom,
Thanks for your help!
It's not through one client. I am using JDBC. But the same things
happen when I use client like psql.
Qing
On Mar 25, 2004, at 10:20 AM, Tom Lane wrote:
Qing Zhao <[EMAIL PROTECTED]> writes:
I have a query which get's data from a single table.
When I try to get data
On Thu, 25 Mar 2004, Qing Zhao wrote:
>select
>_level_ as l,
> nextval('seq_pk_bom_detail') as bom_detail,
> prior nextval('seq_pk_bom_detail') as parent_subassembly,
>parent_part_number,
> customer_part_number,
>/* mfr_name,
> mfr_part,
> description,*/
> c
It is 7.3.4 on MAC OS X (darwin). The patch we applied is hier-Pg7.3-0.5, which allows
to perform hierarchical queries on PgSQL using Oracle's syntax.
Thanks!
Qing
On Mar 25, 2004, at 2:57 PM, Stephan Szabo wrote:
On Thu, 25 Mar 2004, Qing Zhao wrote:
select
_level_ as l,
nextval('seq_pk_bom_
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Thu, 25 Mar 2004, Qing Zhao wrote:
>> start with customer_part_number = 'Top Assembly 1'
>> connect by parent_part_number = prior customer_part_number;
> What version are you running, and did you apply any patches (for example
> one to support the sta
Tom,
> Oh, good eye ... it's that infamous CONNECT BY patch again, without doubt.
Hey, who does this patch? What's wrong wiith it?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searched our l
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Oh, good eye ... it's that infamous CONNECT BY patch again, without doubt.
> Hey, who does this patch? What's wrong wiith it?
I'm just venting my annoyance at people expecting us to support
hacked-up versions, especially without telling us they're hack
Theory B, of course, is that this is an actual bug in the patch and not
just incorrect installation. I'm not interested enough to investigate
though.
Is there still someone around who's working on getting a similar patch
into 7.5? Seems there huge user demand for such a thing...
(And no, I'm
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is there still someone around who's working on getting a similar patch
> into 7.5? Seems there huge user demand for such a thing...
Andrew Overholt did some preliminary work toward implementing the
SQL99-spec WITH functionality (which subsume
Andrew Overholt did some preliminary work toward implementing the
SQL99-spec WITH functionality (which subsumes what CONNECT BY does,
and a few other things too). But he's left Red Hat and gone back
to school. One of the many things on my todo list is to pick up that
patch and get it finished.
Ou
On 25 Mar, Manfred Spraul wrote:
> Tom Lane wrote:
>
>>[EMAIL PROTECTED] writes:
>>
>>
>>>I could certainly do some testing if you want to see how DBT-2 does.
>>>Just tell me what to do. ;)
>>>
>>>
>>
>>Just do some runs that are identical except for the wal_sync_method
>>setting. Note that
[EMAIL PROTECTED] wrote:
> > I've made a test run that compares fsync and fdatasync: The performance
> > was identical:
> > - with fdatasync:
> >
> > http://khack.osdl.org/stp/290607/
> >
> > - with fsync:
> > http://khack.osdl.org/stp/290483/
> >
> > I don't understand why. Mark - is there a b
Bruce,
> We don't actually extend the WAL file during writes (preallocated), and
> the access/modification timestamp is only in seconds, so I wonder of the
> OS only updates the inode once a second. What else would change in the
> inode more frequently than once a second?
What about really big w
On 22 Mar, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> I could certainly do some testing if you want to see how DBT-2 does.
>> Just tell me what to do. ;)
>
> Just do some runs that are identical except for the wal_sync_method
> setting. Note that this should not have any impact on SELECT
> pe
16 matches
Mail list logo
