Re: Compression and on-disk sorting - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Compression and on-disk sorting
Date
Msg-id 12911.1147819713@sss.pgh.pa.us
Whole thread Raw
In response to Re: Compression and on-disk sorting  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> Not seek, mark/restore. As the code describes, sometimes you go back a
> tuple. The primary reason I think is for the final pass, a merge sort
> might read the tuples multiple times, so it needs to support it there.

However it'd be possible to tell logtape in advance whether a particular
tape needs to support that, and only apply compression when not; it
would work all the time for intermediate merge passes, and with the
recent executor changes to pass down you-need-to-support-mark flags,
it'd work for the output pass in a lot of cases too.

If you're just trying to get some quick and dirty numbers: do
compression, replace Seek/Tell with PANICs, and only test on plain
sorts no joins ;-)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Compression and on-disk sorting
Next
From: Greg Stark
Date:
Subject: Re: Compression and on-disk sorting